Currently, only RESTRICT is allowed.

'NOT (x IN (subselect))', that is 'NOT (x = ANY (subselect))',
rather than 'x <> ALL (subselect)' as we formerly did.  This
opens the door to optimizing NOT IN the same way as IN, whereas
there's no hope of optimizing the expression using <>.  Also,
convert 'x <> ALL (subselect)' to the NOT(IN) style, so that
the optimization will be available when processing rules dumped
by older Postgres versions.
initdb forced due to small change in SubLink node representation.

by having to include miscadmin.h into other header files.

interfaces.

per gripe from Csaba Nagy.  There is still potential for platform-specific
behavior for values that are exactly halfway between integers, but at
least we now get the expected answer for all other cases.

causes interval rounding not to work as expected in 7.3, for example
SELECT '18:17:15.6'::interval(0) does not round the value.
I did not force initdb, but one is needed to install the added row.

believe I didn't notice this before -- once 64k was sent to/from the
server the client would crash.  Basicly, in 7.3 the server SSL code set
the initial state to "about to renegotiate" without actually starting
the renegotiation.  In addition, the server and client didn't properly
handle the SSL_ERROR_WANT_(READ|WRITE) error.  This is fixed in the
second patch.

Nathan Mueller

first, that I missed when checking over 7.3.1, was that the client
method was switched to SSLv23 along with the server.  The SSLv23 client
method does SSLv2 by default, but can also understand SSLv3.  In our
situation the SSLv2 backwords compatibility is really only needed on the
server.  This is the first patch.

The last thing is that I found a way for the server to understand SSLv2
HELLO messages (sent by pre-7.3 clients) but then get them to talk
SSLv3.  This is the last one.

Nathan Mueller

> The big problem is that while pg_dump's dump_trigger() looks at
> tginitdeferred and dumps accordingly, pg_get_constraintdef doesn't look
> at tginitdeferred, and therefore doesn't record the requirement as part
> of ALTER TABLE ADD CONSTRAINT.

pg_get_constraintdef should probably be looking at condeferrable and
condeferred in the pg_constraint row it's looking at.  Maybe something
like the attached.

(Added, output only non-default values.)

Stephan Szabo

Neil Conway

proposal on -hackers a couple days ago. The 'tgenabled' status of the
trigger is consulted when the trigger is added to the deferred queue
(i.e. when the event occurs that fires the trigger), not when the
deferred event is executed.

No regression tests, as another bug prevents them (the pg_trigger row
for a trigger is only loaded once per session, so any changes to it are
not noticed unless the client disconnects and reconnects).

Neil Conway

Serguei Mokhov

expressions before they are stored.  This seems like not such a hot idea,
particularly now that the constant-folder will try to inline SQL functions.

on its namespace, so that it will go away if the schema is dropped.

Backpatch to 7.3.X.

Report from ljb.

the index AM when we know we are fetching a unique row.  However, this
logic did not consider the possibility that it would be asked to fetch
backwards.  Also fix mark/restore to work correctly in this scenario.

here, not -1.

right thing with the destination when FETCH 0 can't return a row,
don't try to stuff LONG_MAX into an int value.

much enthusiasm.

(ie, the one with describe-schema support).  Minor code review.
Adjust display of casts to use standard type names.

previously determined not to be the last segment of a relation.
This reduces the expected cost to one seek, rather than one seek per
segment.  We can get away with this because truncation of a relation
will cause a relcache flush and so the md.c file descriptor will be
closed; when it is re-opened we will re-determine the last segment.

if the OS supports it.  Code will still compile on non-IPv6-aware
machines (feature added by Bruce).

Nigel Kukard