Re: potential bug in trigger with boolean params - Mailing list pgsql-hackers

From Andres Freund
Subject Re: potential bug in trigger with boolean params
Date
Msg-id 201105111206.07231.andres@anarazel.de
Whole thread Raw
In response to Re: potential bug in trigger with boolean params  (Andreas Joseph Krogh <andreak@officenet.no>)
Responses Re: potential bug in trigger with boolean params  (Szymon Guz <mabewlun@gmail.com>)
List pgsql-hackers
On Wednesday, May 11, 2011 11:50:35 AM Szymon Guz wrote:
> On 11 May 2011 11:29, Andres Freund <andres@anarazel.de> wrote:
> > On Wednesday, May 11, 2011 11:21:34 AM Andres Freund wrote:
> > > On Wednesday, May 11, 2011 11:01:56 AM Andreas Joseph Krogh wrote:
> > > > På onsdag 11. mai 2011 kl 10:56:19 skrev <tv@fuzzy.cz>:
> > > > > > CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW
> > > > > > EXECUTE PROCEDURE
> > > > > > trigger_x(true);
> > > > >
> > > > > The docs clearly state what the valid values are and the literal
> >
> > 'true'
> >
> > > > > is not one of them (TRUE is). See this:
> > > > >
> > > > > http://www.postgresql.org/docs/9.0/interactive/datatype-boolean.htm
> > > > > l
> > > >
> > > > What are you trying to accomplish? "CREATE OR REPLACE FUNCTION
> > > > trigger_x()" does not declare any formal-parameters, so calling it
> > > > with arguments doesn't make sense. I'm surprised creating the other
> > > > triggers didn't produce an error stating "No function defined with
> > > > the name trigger_ix and the given argument-type".
> > >
> > > Read the docs. Parameters for triggers are not passed as normal
> > > function parameters. Thats why you access them via via TG_ARGV in
> > > plpgsql.
> >
> > > The grammar accepts only a very limited amount of parameters there:
> > Err....
> >
> > TriggerFuncArg:
> >                        Iconst
> >
> >                                {
> >
> >                                        char buf[64];
> >                                        snprintf(buf, sizeof(buf), "%d",
> >
> > $1);
> >
> >                                        $$ = makeString(pstrdup(buf));
> >
> >                                }
> >                        |
> >                        | FCONST
> >
> >                    { $$ = makeString($1); }
> >
> >                        | Sconst
> >
> >                    { $$ = makeString($1); }
> >
> >                        | BCONST
> >
> >                    { $$ = makeString($1); }
> >
> >                        | XCONST
> >
> >                    { $$ = makeString($1); }
> >
> >                        | ColId
> >
> >             { $$ = makeString($1); }
> >
> > That is integers, floating point, strings, bitstrings, hexstrings and
> > column references (???).
> >
> > How that exact list came to exist I do not know.
>
> My two thoughts on that:
>
> 1. This list should be improved to allow booleans, and maybe other types
>
> 2. Why then is it like this:
>
> it works:
> CREATE TRIGGER trig_x_10 BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
> trigger_x('true');
>
> it does not:
> CREATE TRIGGER trig_x_11 BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
> trigger_x('true'::text);
>
> the error is:
> ERROR:  syntax error at or near "::"
>
> I think there is something wrong.
The grammar doesn't allow any form of expression. It only allows the above
listed types of literals directly.
I am not really sure why it was done that way, but its been that way for a
long time (only insignificant changes since 1997... bitstrings and hex strings
were added after that though).

Why do you wan't to use a boolean directly if you can't use it as the type
itself anyway?

Andres


pgsql-hackers by date:

Previous
From: Cédric Villemain
Date:
Subject: Re: the big picture for index-only scans
Next
From: Cédric Villemain
Date:
Subject: Re: the big picture for index-only scans