Re: [SQL] BEFORE UPDATE Triggers
Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: Unfortunately, you're right. There is no way do distinguish in a trigger or rule if a value in the new row did result from the UPDATE query or from target list expansion with OLD values. It would not be terribly hard to examine the original query during executor start, looking for bare OLD referencing Var nodes, and stick something like a flag array into the trigger information. People keep suggesting this, but I've never thought it was a very sane idea. What if some BEFORE trigger upstream of yours changes the column? You won't find that out unless you actually compare the OLD and NEW column values. If you assume the column has not changed just because the original query text didn't change it, you are in for a world of hurt. That's exactly why I allways ask to look at it from a business process point of view. The NEW data that will be persistent when the transaction commits has to match the new status of the business process. Where this data exactly is coming from, got manipulated or how it got there is not really relevant. What counts is that the system transforms from one consistent state into another in an ACID transaction. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [SQL] disabling triggers
On Tue, Jun 17, 2003 at 11:49:44AM -0700, Josh Berkus wrote: I also need something like that for my replication stuff: When data from another node comes it, it should be written directly to the tables, without any (unwanted) triggers firering. On the other hand, in "normal" mode, also some missing fields should be filled on create or update. Perhaps some more details: All tables have this layout: inode_idint4 attrchar mtime timestamp ... On INSERT an missing (NULL) inode_id should be taken from sequence _inode_seq, attr can be set to an default value (currently not important) and an NULL mtime should be replaced by current_timestamp(). When UPDATE-ing, the mtime should also be set to current_timestamp() if not given. But in the "raw" mode (when data from neighbours come in), the mtime field may _not_ be touched (since it would produce an loop!). Currently this is done by the middleware, but I'd like to have it directly in the RDBMS. How could this be solved ? regards -- - Enrico Weigelt== metux IT services phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - Diese Mail wurde mit UUCP versandt. http://www.metux.de/uucp/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[SQL] Trigger functions w/o pgsql ?
Hi folks, is it somehow possible to create trigger functions directly in SQL language, w/o an procedural language ? Why cant the return value of an function simply be ignored, instead of requiring the function to return void (which an sql function can't return) ? cu -- - Enrico Weigelt== metux IT services phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - Diese Mail wurde mit UUCP versandt. http://www.metux.de/uucp/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Trigger functions w/o pgsql ?
[EMAIL PROTECTED] writes: > is it somehow possible to create trigger functions directly in > SQL language, w/o an procedural language ? No. > Why cant the return value of an function simply be ignored, > instead of requiring the function to return void (which an sql > function can't return) ? Internal reasons mostly, but not trivial to overcome. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
