Re: transition tables and UPDATE

>
>
> even uglier than what I already had. So yeah, I think it might be
> useful if we had a way to inject a counter or something in there.
>
>
This came up for me when I was experimenting with making the referential
integrity triggers fire on statements rather than rows. Doing so has the
potential to take a lot of the sting out of big deletes where the
referencing column isn't indexed (thus resulting in N sequentials scans of
the referencing table). If that were 1 statement then we'd get a single
(still ugly) hash join, but it's an improvement.

It has been suggested that the the overhead of forming the tuplestores of
affected rows and reconstituting them into EphemerialNamedRelations could
be made better by instead storing an array of old ctids and new ctids,
which obviously would be in the same order, if we had a means of
reconstituting those with just the columns needed for the check (and
generating a fake ordinality column for your needs), that would be
considerably lighter weight than the tuplestores, and it might make
statement level triggers more useful all around.