On Tue, Nov 22, 2005 at 11:57:48AM +0100, Martijn van Oosterhout wrote: <excellent research snipped>
> Rather than trying to make MERGE do something it wasn't designed for, > we should probably be spending our efforts on triggers for error > conditions. Maybe something like: > > CREATE TRIGGER foo AFTER ERROR ON bar EXECUTE baz(); > > Where baz would be passed NEW and OLD just like a normal trigger and if > the trigger return NULL, the update is ignored. In the meantime the > function can divert the insert to another table if it likes. This seems > like a much more workable and useful addition. I agree that we shouldn't try and distort MERGE into something fancy. The AFTER ERROR trigger is a very interesting idea, since it could handle many different cases. But I'm worried that people might not want that behavior on by default for everything done against some table. I think it'd be better to have some way to specify in a command that you want to use some kind of error-handling trigger. Though presumably the underlying framework would be same, so it shouldn't be hard to support both. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
