Re: System triggers - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: System triggers
Date
Msg-id 3ECA085F.5040309@Yahoo.com
Whole thread Raw
In response to System triggers  (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>)
List pgsql-hackers
Doug McNaught wrote:
> Sailesh Krishnamurthy <sailesh@cs.berkeley.edu> writes:
> 
> 
>>>>>>>"Doug" == Doug McNaught <doug@mcnaught.org> writes:
>>>>>>
>>    Doug> Of course, what happens to the output (if any) from those
>>    Doug> triggers, given that the client probably doesn't expect it,
>>    Doug> is an interesting question...
>>
>>What are the actions of pgsql triggers ? I would have thought they
>>result in Update/Delete/Insert operations on other tables. Why should
>>that result in output for any client ? 
> 
> 
> They still (IIRC) return results (like 'INSERT 1 10002') to the
> client end of the connection, and there's no a-priori reason they
> couldn't do SELECTS as well...

They don't, I guess you mix something here with rules or INSERT INTO.

Triggers are fired during or after INSERT, UPDATE and DELETE operations
(so far). Other than reducing the number of tuples affected by returning
NULL in a BEFORE trigger, they do not change the response to the client
at all. They can cause NOTIFY or ERROR messages to be added to the
client communication stream, but that's something to expect at any time.
No trigger will cause an INSERT all of the sudden to return result rows.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: AnonCVS not quite there yet
Next
From: Christopher Browne
Date:
Subject: Re: Heads up: 7.3.3 this Wednesday