Re: [Bug Fix] ECPG: could not use set xxx to default statement

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>, "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Bug Fix] ECPG: could not use set xxx to default statement
Date: 2019-02-19 14:47:31
Message-ID: a7fcb720-29b1-caff-2383-12329bbdb0dd@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2/19/19 9:29 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> I just looked at the bison manual at gnu.org and also at `info bison` on
>> my local machine, and couldn't see any reference to semicolons being
>> optional at the end of a rule. Under the heading "Syntax of Grammar
>> Rules" it says this:
>> A Bison grammar rule has the following general form:
>>      RESULT: COMPONENTS...;
>> Making it optional without putting that in the manual is just awful.
> Yeah. I wonder if they removed that info in 1.34 and failed to
> put it back in 1.875?
>
> Anyway, I'm of the opinion that omitting the semi is poor style
> and our tools should insist on it even if Bison does not. Thus,
> I think the correct fix is for the scripts to complain about a
> missing semi, not cope.

Yeah, agreed.

>
> My initial look at parse.pl last night left me feeling pretty
> disheartened about its robustness in general --- for example,
> it looks like { } /* or */ inside a string literal or Bison
> character token would break it completely, because it wouldn't
> distinguish those cases from the same things outside a string.
> It's just luck we haven't broken it yet (or, perhaps, we have
> and nobody exercised the relevant productions yet?).
>
> Probably, somebody who's a better Perl programmer than me
> ought to take point on improving that.
>
>

Agreed.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-02-19 14:56:58 Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)
Previous Message Peter Eisentraut 2019-02-19 14:47:01 Re: insensitive collations