Re: BUG #13708: strange behaviour instead of syntax error - Mailing list pgsql-bugs

From Pavel Stehule
Subject Re: BUG #13708: strange behaviour instead of syntax error
Date
Msg-id CAFj8pRDMbPPUkzPsKmVyFoFDiFGOP_ocL3uShc+ZE8hrdvDdnA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #13708: strange behaviour instead of syntax error  (Greg Stark <stark@mit.edu>)
List pgsql-bugs
2015-10-24 14:04 GMT+02:00 Greg Stark <stark@mit.edu>:

>
> On 24 Oct 2015 00:03, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> >
> > Hmmm ... maybe just adding parens would do the trick.
> >
> > regression=# SELECT ('ERROR: No uncollected prize found!' RETURN);
> > ERROR:  syntax error at or near "RETURN"
> >
> > That looks more promising ... though I'm not sure if there are
> > any cases it would break.
>
> That does seem like a good idea. There are plennty of keywords that can
> follow a target list that would lead to strange behaviour, not the last of
> which would be FROM... Adding parentheses should mean only a valid
> expression should be accepted.
>
I used same technique in PLPSM - and it is working. But If I remember well,
there will be complication with multi assign SET (a,b,c) = (10,2,3) because
I had other level of nesting. But PLpgSQL doesn't support thes feature.

Cannot be used a bison functionality - "multiple start points"
http://www.gnu.org/software/bison/manual/html_node/Multiple-start_002dsymbols.html
?

Regards

Pavel

pgsql-bugs by date:

Previous
From: Jeff Janes
Date:
Subject: Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.
Next
From: chjischj@163.com
Date:
Subject: BUG #13723: "duplicate key" error occurs when update delete and insert the same row concurrently