On 10/8/14, 5:51 PM, Peter Geoghegan wrote:
> On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner<kgrittn@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
stuckin a loop where a BEFORE INSERT trigger turns the tuple into an UPDATE and a BEFORE UPDATE trigger turns it into
anINSERT.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
