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

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com>
Cc: 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 09:26:51
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, 2019-02-19 at 00:05 -0500, Tom Lane wrote:
> I wrote:
> > "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com> writes:
> > > [ missing semicolon in gram.y breaks ecpg parsing of same
> > > construct ]
> > That's pretty nasty. The fix in gram.y is certainly needed, but
> > I'm
> > unexcited by the regression test additions you propose. What I
> > really
> > want to know is why a syntax error in gram.y wasn't detected by any
> > of the tools we use,

I'm actually surprised it only shows by one incorrectly working rule
and did not mangle the whole file by combining to rules. I guess that's
because bison now finds the end of the rule somehow even without the

> But it doesn't. It seems though that our conversion script for
> creating
> preproc.y depends on there being semicolons.

Yes, it does. There has to be a way for the script to find the end of a
rule and I wonder if bison's way can be used in such a simple perl
script too.

> I think we need to fix that script to either cope with missing
> semicolons,
> or at least complain about them. Too tired to look into how, right
> now.

If we can identify a missing semicolon we probably can also figure out
where it had to be.

Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Higuchi, Daisuke 2019-02-19 09:38:01 RE: [Bug Fix] ECPG: could not use set xxx to default statement
Previous Message Konstantin Knizhnik 2019-02-19 09:26:04 Re: Prepared transaction releasing locks before deregistering its GID