Query used for checking foreign key triggers
returns too many results when there're more than one foreign
key in a table. It happens because only table's oid is used to
link between pg_trigger with INSERT check and pg_trigger with
UPDATE/DELETE check.

I think there should be enough to add following conditions
into WHERE clause of that query:
        AND     pt.tgconstrname = pg_trigger.tgconstrname
        AND     pt.tgconstrname = pg_trigger_1.tgconstrname

/Constantin

bothering to check the return value --- which meant that in case the
update or delete failed because of a concurrent update, you'd not find
out about it, except by observing later that the transaction produced
the wrong outcome.  There are now subroutines simple_heap_update and
simple_heap_delete that should be used anyplace that you're not prepared
to do the full nine yards of coping with concurrent updates.  In
practice, that seems to mean absolutely everywhere but the executor,
because *noplace* else was checking.

attributes in a FieldSelect node --- all the places that manipulate
these work just fine with system attribute numbers.  OK, it's a new
feature, so shoot me ...

at end of its block, maybe we can enlarge it in-place.

into new chapter on query (SELECT) syntax.  In the end this should become
a narrative and example-filled counterpart to the SELECT reference page.

eliminates a raft of portability issues, including whether sys_nerr
exists, whether the platform has any valid negative errnos, etc.  The
downside is minimal: errno shouldn't ever contain an invalid value anyway,
and if it does, reasonably modern versions of strerror will not choke.
This rangecheck idea seemed good at the time, but it's clearly a net loss,
and I apologize to all concerned for having ever put it in.

rewrite of deadlock checking.  Lock holder objects are now reachable from
the associated LOCK as well as from the owning PROC.  This makes it
practical to find all the processes holding a lock, as well as all those
waiting on the lock.  Also, clean up some of the grottier aspects of the
SHMQueue API, and cause the waitProcs list to be stored in the intuitive
direction instead of the nonintuitive one.  (Bet you didn't know that
the code followed the 'prev' link to get to the next waiting process,
instead of the 'next' link.  It doesn't do that anymore.)

expression evaluation.

Easter <reaster@comptechnews.com>, heavily massaged by me.  Also cleaned up
value expressions a bit.