Michael Meskes writes:
>> Not seeing any motion on this, here's a draft patch to make these
>> scripts complain about missing semicolons. Against the current
>> gram.y (which contains 2 such errors, as Michael noted) you
>> get output like
> Thanks Tom for looking into this. Are we agreed then t
> Not seeing any motion on this, here's a draft patch to make these
> scripts complain about missing semicolons. Against the current
> gram.y (which contains 2 such errors, as Michael noted) you
> get output like
Thanks Tom for looking into this. Are we agreed then that we want
gram.y to have sem
Andrew Dunstan writes:
> On 2/19/19 9:29 AM, Tom Lane wrote:
>> Probably, somebody who's a better Perl programmer than me
>> ought to take point on improving that.
> Agreed.
Not seeing any motion on this, here's a draft patch to make these
scripts complain about missing semicolons. Against the
On 2/19/19 9:29 AM, Tom Lane wrote:
> Andrew Dunstan 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 say
Andrew Dunstan 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 f
On 2/19/19 6:21 AM, Michael Meskes wrote:
> Higuchi-san,
>
>> I attached the patch which cope with missing semicolons.
>> Previous parse.pl find semicolon and dump data to buffer. When
>> attached patch's parse.pl find new tokens before finding a semicolon,
>> it also dumps data to buffer.
> It
Higuchi-san,
> I attached the patch which cope with missing semicolons.
> Previous parse.pl find semicolon and dump data to buffer. When
> attached patch's parse.pl find new tokens before finding a semicolon,
> it also dumps data to buffer.
It just occurred to me that check_rules.pl probably use
Higuchi-san,
> I attached the patch which cope with missing semicolons.
> Previous parse.pl find semicolon and dump data to buffer. When
> attached patch's parse.pl find new tokens before finding a semicolon,
> it also dumps data to buffer.
Now this seems to be much easier than I expected. Thank
Hi,
> 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.
I attached the patch which cope with missing semicolons.
Previous parse.pl find semicolon and dump data to buffer. When attached patch's
p
On Tue, 2019-02-19 at 00:05 -0500, Tom Lane wrote:
> I wrote:
> > "Higuchi, Daisuke" 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
I wrote:
> "Higuchi, Daisuke" 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 gr
"Higuchi, Daisuke" 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 detect
Hi,
I found ECPG's bug which SET xxx = DEFAULT statement could not be used.
[PROBLEM]
When the source code (*.pgc) has "EXEC SQL set xxx = default;", created c
program by ECPG has no " = default".
For example, "EXEC SQL set search_path = default;" in *.pgc will be converted
to "{ ECPGdo(__LI
13 matches
Mail list logo
