On 10/8/14, 5:51 PM, Peter Geoghegan wrote:
On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner<kgri...@ymail.com> wrote:
>Although the last go-around does suggest that there is at least one
>point of difference on the semantics. You seem to want to fire the
>BEFORE INSERT triggers before determining whether this will be an
>INSERT or an UPDATE. That seems like a bad idea to me, but if the
>consensus is that we want to do that, it does argue for your plan
>of making UPSERT a variant of the INSERT command.
Well, it isn't that I'm doing it because I think that it is a great
idea, with everything to recommend it. It's more like I don't see any
practical alternative. We need the before row insert triggers to fire
to figure out what to insert (or if we should update instead). No way
around that. At the same time, those triggers are at liberty to do
almost anything, and so in general we have no way of totally
nullifying their effects (or side effects). Surely you see the
dilemma.
FWIW, if each row was handled in a subtransaction then an insert that turned
out to be an update could be rolled back... but the performance impact of going
that route might be pretty horrid. :( There's also the potential to get stuck
in a loop where a BEFORE INSERT trigger turns the tuple into an UPDATE and a
BEFORE UPDATE trigger turns it into an INSERT.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
