Re: BUG #13708: strange behaviour instead of syntax error

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, yozh(dot)ne(at)gmail(dot)com
Subject: Re: BUG #13708: strange behaviour instead of syntax error
Date: 2015-10-25 03:14:26
Message-ID: CAFj8pRDMbPPUkzPsKmVyFoFDiFGOP_ocL3uShc+ZE8hrdvDdnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

2015-10-24 14:04 GMT+02:00 Greg Stark <stark(at)mit(dot)edu>:

>
> On 24 Oct 2015 00:03, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message chjischj 2015-10-25 11:01:36 BUG #13723: "duplicate key" error occurs when update delete and insert the same row concurrently
Previous Message Jeff Janes 2015-10-24 17:28:17 Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.