On Sun, Aug 16, 2009 at 05:59:46PM +0200, Boszormenyi Zoltan wrote:
What heppens if the sqlda is incompatible?
Returns false?
I wasn't talking about this one function but about the flow of the resulting
program. How can it happen that sqlda is incompatible and what happens then?
Michael
--
On Fri, Aug 14, 2009 at 10:12:24PM +0200, Boszormenyi Zoltan wrote:
Will add the ecpg_log(). What the code does is:
- sets up a minimal SQLDA on the first call (called with NULL ptr),
so the field types and field names and some other properties are in place.
doesn't do further work if out
Michael Meskes írta:
On Fri, Aug 14, 2009 at 10:12:24PM +0200, Boszormenyi Zoltan wrote:
Will add the ecpg_log(). What the code does is:
- sets up a minimal SQLDA on the first call (called with NULL ptr),
so the field types and field names and some other properties are in place.
On Mon, Aug 03, 2009 at 06:12:43PM +0200, Boszormenyi Zoltan wrote:
- sqlda support:
- sqlda.c now indicates license
- #defines inside #if 0 ... #endif are now omitted from sqltypes.h
(both per comments from Jaime Casanova)
I still owe you some first thoughts about this part of the
Michael Meskes írta:
On Mon, Aug 03, 2009 at 06:12:43PM +0200, Boszormenyi Zoltan wrote:
- sqlda support:
- sqlda.c now indicates license
- #defines inside #if 0 ... #endif are now omitted from sqltypes.h
(both per comments from Jaime Casanova)
I still owe you some first
Tom Lane wrote:
So I'd like to see an actual case made
that there's a strong reason for not requiring FROM/IN in ecpg.
I guess there's only one, compatibility.
Yeah. Are there any other precompilers that actively reject FROM/IN
here? If we're just a bit more strict than they are, it's
Boszormenyi Zoltan írta:
OK, here's the WIP patch for the unified core/ecpg grammar,
with opt_from_in. But I am still getting the 2 shift/reduce
conflicts exactly for the FORWARD and BACKWARD rules
that I was getting originally. Can you look at this patch and
point me to the right direction
Tom Lane írta:
I wrote:
The fundamental reason that there's a problem here is that ecpg has
decided to accept a syntax that the backend doesn't (ie, FETCH with a
fetch direction but no FROM/IN). I think that that's basically a bad
idea: it's not helpful to users to be inconsistent, and
Boszormenyi Zoltan írta:
Tom Lane írta:
I wrote:
The fundamental reason that there's a problem here is that ecpg has
decided to accept a syntax that the backend doesn't (ie, FETCH with a
fetch direction but no FROM/IN). I think that that's basically a bad
idea: it's not
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I'd look at requiring from_in as being the least-bad alternative.
Hm. FETCH FORWARD variable can only be a rowcount var
only if there's something afterwards, no? With the proposed
change in
On Sat, Aug 08, 2009 at 04:57:57PM -0400, Tom Lane wrote:
The fundamental reason that there's a problem here is that ecpg has
decided to accept a syntax that the backend doesn't (ie, FETCH with a
fetch direction but no FROM/IN). I think that that's basically a bad
Which was added because most
On Sat, Aug 08, 2009 at 05:29:06PM -0400, Tom Lane wrote:
around nontrivial expressions. So I'd like to see an actual case made
that there's a strong reason for not requiring FROM/IN in ecpg.
I guess there's only one, compatibility.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De,
Michael Meskes mes...@postgresql.org writes:
On Sat, Aug 08, 2009 at 05:29:06PM -0400, Tom Lane wrote:
around nontrivial expressions. So I'd like to see an actual case made
that there's a strong reason for not requiring FROM/IN in ecpg.
I guess there's only one, compatibility.
Yeah. Are
Michael Meskes írta:
On Sat, Aug 08, 2009 at 04:57:57PM -0400, Tom Lane wrote:
The fundamental reason that there's a problem here is that ecpg has
decided to accept a syntax that the backend doesn't (ie, FETCH with a
fetch direction but no FROM/IN). I think that that's basically a bad
Boszormenyi Zoltan írta:
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I'd look at requiring from_in as being the least-bad alternative.
Hm. FETCH FORWARD variable can only be a rowcount var
only if there's
On Fri, Aug 07, 2009 at 04:03:38PM +0200, Boszormenyi Zoltan wrote:
I added notice about the PostgreSQL license. Is it ok?
Or should I resend without indicating the authors?
Normally all our source files are Copyright PostgreSQL Global Development
Group and I don't see a reason why this should
On Fri, Aug 07, 2009 at 12:08:00PM -0400, Alvaro Herrera wrote:
I think we're normally OK with mentioning the authors, i.e. Author:
Yes, it's OK, but I think we normally only acknowledge the author in our commit
messages, don't we?
such and such, but the (C) line should attribute copyright to
Michael Meskes írta:
On Fri, Aug 07, 2009 at 12:08:00PM -0400, Alvaro Herrera wrote:
I think we're normally OK with mentioning the authors, i.e. Author:
Yes, it's OK, but I think we normally only acknowledge the author in our
commit
messages, don't we?
such and such, but the
On Mon, Aug 03, 2009 at 06:59:30PM +0200, Boszormenyi Zoltan wrote:
Why is this messing with the core grammar?
...
Zoltan, could you please explain why you unrolled FORWARD and BACKWARD? I tried
applying the rest of your patch, without this unrolling but didn't get any
shift/reduce problem.
Michael Meskes mes...@postgresql.org writes:
Tom, AFAICT we only need one core grammar change, moving the cursor name to
it's own rule that only resolves back to name. This rule should be eliminated
by bison during the build process anyway, so I see no problem adding it. It
does make the ecpg
Michael Meskes írta:
On Mon, Aug 03, 2009 at 06:59:30PM +0200, Boszormenyi Zoltan wrote:
Why is this messing with the core grammar?
...
Zoltan, could you please explain why you unrolled FORWARD and BACKWARD? I
tried
applying the rest of your patch, without this unrolling
Tom Lane írta:
Michael Meskes mes...@postgresql.org writes:
Tom, AFAICT we only need one core grammar change, moving the cursor name to
it's own rule that only resolves back to name. This rule should be eliminated
by bison during the build process anyway, so I see no problem adding it. It
On Sat, Aug 08, 2009 at 05:48:57PM +0200, Boszormenyi Zoltan wrote:
...
/usr/bin/perl ./parse.pl . ../../../../src/backend/parser/gram.y
preproc.y
/usr/bin/bison -d -o preproc.c preproc.y
preproc.y: conflicts: 2 shift/reduce
preproc.y: expected 0 shift/reduce conflicts
make[4]: ***
Michael Meskes írta:
On Sat, Aug 08, 2009 at 05:48:57PM +0200, Boszormenyi Zoltan wrote:
...
/usr/bin/perl ./parse.pl . ../../../../src/backend/parser/gram.y
preproc.y
/usr/bin/bison -d -o preproc.c preproc.y
preproc.y: conflicts: 2 shift/reduce
preproc.y: expected 0 shift/reduce
On Sat, Aug 08, 2009 at 07:21:59PM +0200, Boszormenyi Zoltan wrote:
A possible solution
would be to force a numeric variable for numeric data.
By which you would remove a feature.
With the proposed core grammar change,
the feature where you can pass the number of
records to be fetched
Michael Meskes írta:
On Sat, Aug 08, 2009 at 07:21:59PM +0200, Boszormenyi Zoltan wrote:
A possible solution
would be to force a numeric variable for numeric data.
By which you would remove a feature.
With the proposed core grammar change,
the feature where you can pass the
Boszormenyi Zoltan z...@cybertec.at writes:
Michael Meskes Ãrta:
The problem is that SignedIconst might be a char variable,
too. So how shall the parser know whether str in FETCH BACKWARD :str
carries
the number of records to move backwards ot the cursor name.
This was the problem, yes.
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Michael Meskes Ărta:
The problem is that SignedIconst might be a char variable,
too. So how shall the parser know whether str in FETCH BACKWARD :str
carries
the number of records to move backwards ot the cursor name.
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I'd look at requiring from_in as being the least-bad alternative.
Hm. FETCH FORWARD variable can only be a rowcount var
only if there's something afterwards, no? With the proposed
change in fetch_direction (moving FORWARD and
I wrote:
The fundamental reason that there's a problem here is that ecpg has
decided to accept a syntax that the backend doesn't (ie, FETCH with a
fetch direction but no FROM/IN). I think that that's basically a bad
idea: it's not helpful to users to be inconsistent, and it requires ugly
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I'd look at requiring from_in as being the least-bad alternative.
Hm. FETCH FORWARD variable can only be a rowcount var
only if there's something afterwards, no? With the proposed
change in
On Mon, Aug 03, 2009 at 06:12:43PM +0200, Boszormenyi Zoltan wrote:
- string support: I am doing much less now unconditionally,
most of the parser changes (e.g. introducing STRING_P)
were unnecessary to make it working.
I took the freedom to rewrite some parts of this patch and the
Michael Meskes írta:
On Mon, Aug 03, 2009 at 06:12:43PM +0200, Boszormenyi Zoltan wrote:
- string support: I am doing much less now unconditionally,
most of the parser changes (e.g. introducing STRING_P)
were unnecessary to make it working.
I took the freedom to rewrite
On Fri, Aug 07, 2009 at 01:05:33PM +0200, Boszormenyi Zoltan wrote:
Hey, thanks. Did you only commit this, or all of
those in the patchset? Exluding the nonfix for
the struct problem of course.
So far only this. So there are three more left to go. :-)
Did you take care of the
Michael Meskes írta:
On Fri, Aug 07, 2009 at 01:05:33PM +0200, Boszormenyi Zoltan wrote:
Hey, thanks. Did you only commit this, or all of
those in the patchset? Exluding the nonfix for
the struct problem of course.
So far only this. So there are three more left to go. :-)
Okay
Boszormenyi Zoltan wrote:
Michael Meskes írta:
Did you take care of the copyright/licensing issue with sqlda?
I added notice about the PostgreSQL license. Is it ok?
Or should I resend without indicating the authors?
I think we're normally OK with mentioning the authors, i.e. Author:
such
Boszormenyi Zoltan z...@cybertec.at writes:
new versions attached, updated to apply to the current CVS cleanly.
Why is this messing with the core grammar?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
new versions attached, updated to apply to the current CVS cleanly.
Why is this messing with the core grammar?
regards, tom lane
It was explained in earlier mails, let me explain it again
but a
Michael Meskes írta:
On Wed, Jul 15, 2009 at 07:17:17PM +0200, Böszörményi Zoltán wrote:
as asked by Michael Meskes, I have split up our ECPG patchset:
Just a couple quick comments.
It appears to me (without much testing) that the patches still partly rely on
each other. But I
On Wed, Jul 15, 2009 at 07:17:17PM +0200, Böszörményi Zoltán wrote:
as asked by Michael Meskes, I have split up our ECPG patchset:
Just a couple quick comments.
It appears to me (without much testing) that the patches still partly rely on
each other. But I cannot see a reason for this.
1.
40 matches
Mail list logo
