Skip site navigation (1) Skip section navigation (2)

Re: Triggers with DO functionality

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Triggers with DO functionality
Date: 2012-02-17 21:07:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On 02/17/2012 03:58 PM, Thom Brown wrote:
> On 17 February 2012 20:40, Dimitri Fontaine<dimitri(at)2ndquadrant(dot)fr>  wrote:
>> Thom Brown<thom(at)linux(dot)com>  writes:
>>> And thinking about it, DO is a bit nonsense here, so maybe we'd just
>>> have something like:
>>> AS $$
>>> END;
>>> $$;
>>> i.e. the same as a function.
>> I like that.  How do you tell which language the trigger is written in?
> Exactly the same as a function I'd imagine.  Just tack LANGUAGE
> <language>; at the end.
>> I'm not so sure about other function properties (SET, COST, ROWS,
>> SECURITY DEFINER etc) because applying default and punting users to go
>> use the full CREATE FUNCTION syntax would be a practical answer here.
> *shrug* There's also the question about the stability of the trigger's
> own in-line function too (i.e. IMMUTABLE, STABLE, VOLATILE).

This is going to be pretty much a piece of syntactic sugar. Would it 
matter that much if the trigger functions made thus are all volatile? If 
someone wants the full function feature set they can always use CREATE 
FUNCTION first. I think I'm with Dimitri - let's keep it simple.



In response to


pgsql-hackers by date

Next:From: Thom BrownDate: 2012-02-17 21:16:33
Subject: Re: Triggers with DO functionality
Previous:From: Thom BrownDate: 2012-02-17 20:58:59
Subject: Re: Triggers with DO functionality

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group