On 2014-09-16 13:54:49 +0100, Thom Brown wrote:
> On 16 September 2014 13:45, Andres Freund wrote:
> > On 2014-09-16 13:42:22 +0100, Thom Brown wrote:
> > > > > The function can't be the target of CREATE OR REPLACE FUNCTION.
> > > >
> > > > That *really* sucks. To the point of making the feature u
On 16 September 2014 13:45, Andres Freund wrote:
> On 2014-09-16 13:42:22 +0100, Thom Brown wrote:
> > > > The function can't be the target of CREATE OR REPLACE FUNCTION.
> > >
> > > That *really* sucks. To the point of making the feature useless in my
> > > eyes. That's really something frequent
On 2014-09-16 13:42:22 +0100, Thom Brown wrote:
> > > The function can't be the target of CREATE OR REPLACE FUNCTION.
> >
> > That *really* sucks. To the point of making the feature useless in my
> > eyes. That's really something frequently done.
> >
>
> Why not CREATE OR REPLACE TRIGGER? Wouldn'
On 16 September 2014 13:29, Andres Freund wrote:
> On 2014-09-16 13:15:59 +0100, Thom Brown wrote:
> > On 17 February 2012 22:42, Jaime Casanova wrote:
> >
> > > On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane wrote:
> > > >
> > > > Has anybody stopped to look at the SQL standard for this? In-line
>
On 2014-09-16 13:15:59 +0100, Thom Brown wrote:
> On 17 February 2012 22:42, Jaime Casanova wrote:
>
> > On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane wrote:
> > >
> > > Has anybody stopped to look at the SQL standard for this? In-line
> > > trigger definitions are actually what they intend, IIRC.
On 17 February 2012 22:42, Jaime Casanova wrote:
> On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane wrote:
> >
> > Has anybody stopped to look at the SQL standard for this? In-line
> > trigger definitions are actually what they intend, IIRC.
> >
>
> this is what i found there
>
> ::=
> CREATE TRIGG
On fre, 2012-02-24 at 13:55 -0600, Kevin Grittner wrote:
> > By default, a trigger function runs as the table owner, ie it's
> implicitly SEC DEF
> > to the table owner.
>
> Really? That's certainly what I would *want*, but it's not what I've
> seen.
Yes, you're right, that was my recollection
On Fri, Feb 24, 2012 at 2:55 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> By default, a trigger function runs as the table owner, ie it's
> implicitly SEC DEF
>> to the table owner.
>
> Really? That's certainly what I would *want*, but it's not what I've
> seen.
Yeah, not quite consistent w
Tom Lane wrote:
> By default, a trigger function runs as the table owner, ie it's
implicitly SEC DEF
> to the table owner.
Really? That's certainly what I would *want*, but it's not what I've
seen.
test=# create user bob;
CREATE ROLE
test=# create user ted;
CREATE ROLE
test=# alter database
On fre, 2012-02-24 at 14:27 -0500, Tom Lane wrote:
> (Thinks some more...) Actually, the point of SECURITY DEFINER on a
> trigger function is to run as somebody other than the table owner,
> to wit the function owner. And with an anonymous function there
> couldn't be any other owner. So I guess
Peter Eisentraut writes:
> On fre, 2012-02-17 at 16:46 -0500, Tom Lane wrote:
>> But perhaps SECURITY DEFINER is a common enough need to justify
>> including in this shorthand form.
> According to the SQL standard, trigger actions run in security definer
> mode. I would hope that we could go wit
On fre, 2012-02-17 at 16:46 -0500, Tom Lane wrote:
> But perhaps SECURITY DEFINER is a common enough need to justify
> including in this shorthand form.
According to the SQL standard, trigger actions run in security definer
mode. I would hope that we could go with that by default for inline
trigg
On Thu, Feb 23, 2012 at 08:26:47AM +, Thom Brown wrote:
> On 23 February 2012 07:15, Gianni Ciolli wrote:
> > Another complication: anonymous triggers would either have to be
> > alone, or provide a mechanism to manage a sequence of anonymous
> > triggers on the same table (such as "replace th
On 23 February 2012 07:15, Gianni Ciolli wrote:
> On Fri, Feb 17, 2012 at 11:43:53AM -0500, Andrew Dunstan wrote:
>> On 02/17/2012 11:29 AM, David E. Wheeler wrote:
>> >On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
>> >>The purpose being to only have a single statement to set up the
>> >>trigger
On Fri, Feb 17, 2012 at 11:43:53AM -0500, Andrew Dunstan wrote:
> On 02/17/2012 11:29 AM, David E. Wheeler wrote:
> >On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
> >>The purpose being to only have a single statement to set up the
> >>trigger rather than setting up a separate trigger function whic
On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane wrote:
>
> Has anybody stopped to look at the SQL standard for this? In-line
> trigger definitions are actually what they intend, IIRC.
>
this is what i found there
::=
CREATE TRIGGER
ON [ REFERENCING ]
::=
[ FOR EACH { ROW | ST
Dimitri Fontaine writes:
> Tom Lane writes:
>> Has anybody stopped to look at the SQL standard for this? In-line
>> trigger definitions are actually what they intend, IIRC.
> In which language? Do we need to include PL/PSM to be compliant, and
> use that by default?
Darn if I know. But let's
Tom Lane writes:
> Has anybody stopped to look at the SQL standard for this? In-line
> trigger definitions are actually what they intend, IIRC.
In which language? Do we need to include PL/PSM to be compliant, and
use that by default? In that case we might want to force people to
spell out LANG
Andrew Dunstan writes:
> On 02/17/2012 03:58 PM, Thom Brown wrote:
>> On 17 February 2012 20:40, Dimitri Fontaine wrote:
>>> 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 FUNCTIO
On 17 February 2012 21:07, Andrew Dunstan wrote:
>
>
> On 02/17/2012 03:58 PM, Thom Brown wrote:
>>
>> On 17 February 2012 20:40, Dimitri Fontaine
>> wrote:
>>>
>>> Thom Brown writes:
And thinking about it, DO is a bit nonsense here, so maybe we'd just
have something like:
>>
On 02/17/2012 03:58 PM, Thom Brown wrote:
On 17 February 2012 20:40, Dimitri Fontaine wrote:
Thom Brown writes:
And thinking about it, DO is a bit nonsense here, so maybe we'd just
have something like:
CREATE TRIGGER...
AS $$
BEGIN
END;
$$;
i.e. the same as a function.
I like that. How
On 17 February 2012 20:40, Dimitri Fontaine wrote:
> Thom Brown writes:
>> And thinking about it, DO is a bit nonsense here, so maybe we'd just
>> have something like:
>>
>> CREATE TRIGGER...
>> AS $$
>> BEGIN
>> END;
>> $$;
>>
>> i.e. the same as a function.
>
> I like that. How do you tell whi
Thom Brown writes:
> And thinking about it, DO is a bit nonsense here, so maybe we'd just
> have something like:
>
> CREATE TRIGGER...
> AS $$
> BEGIN
> END;
> $$;
>
> i.e. the same as a function.
I like that. How do you tell which language the trigger is written in?
I'm not so sure about other
On 17 February 2012 17:26, Peter Eisentraut wrote:
> On fre, 2012-02-17 at 13:22 +, Thom Brown wrote:
>> So instead of
>>
>> CREATE TRIGGER...
>> EXECUTE PROCEDURE functioname();
>>
>> you'd have:
>>
>> CREATE TRIGGER...
>> DO $$
>> ...
>> $$;
>
> I had wished for this many times and was about
On fre, 2012-02-17 at 13:22 +, Thom Brown wrote:
> So instead of
>
> CREATE TRIGGER...
> EXECUTE PROCEDURE functioname();
>
> you'd have:
>
> CREATE TRIGGER...
> DO $$
> ...
> $$;
I had wished for this many times and was about to propose something
similar.
We might wish to review the SQL
On 02/17/2012 11:46 AM, Thom Brown wrote:
On 17 February 2012 16:43, Andrew Dunstan wrote:
On 02/17/2012 11:29 AM, David E. Wheeler wrote:
On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
The purpose being to only have a single statement to set up the
trigger rather than setting up a separa
On 17 February 2012 16:43, Andrew Dunstan wrote:
>
>
> On 02/17/2012 11:29 AM, David E. Wheeler wrote:
>>
>> On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
>>
>>> The purpose being to only have a single statement to set up the
>>> trigger rather than setting up a separate trigger function which wi
On 17 February 2012 16:29, David E. Wheeler wrote:
> On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
>
>> The purpose being to only have a single statement to set up the
>> trigger rather than setting up a separate trigger function which will
>> unlikely be re-used by other triggers... or is this o
On 02/17/2012 11:29 AM, David E. Wheeler wrote:
On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
The purpose being to only have a single statement to set up the
trigger rather than setting up a separate trigger function which will
unlikely be re-used by other triggers... or is this of dubious
b
On Feb 17, 2012, at 5:22 AM, Thom Brown wrote:
> The purpose being to only have a single statement to set up the
> trigger rather than setting up a separate trigger function which will
> unlikely be re-used by other triggers... or is this of dubious
> benefit?
+1, though I imagine it would just g
Hi,
This may have already been discussed before, but I can't find any
mention of it. Would it be desirable to add support for triggers that
contain their own anonymous functions (i.e. DO)?
So instead of
CREATE TRIGGER...
EXECUTE PROCEDURE functioname();
you'd have:
CREATE TRIGGER...
DO $$
...
31 matches
Mail list logo
