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
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 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 o
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 s
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 p
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 directi
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 the
Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> Boszormenyi Zoltan 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 v
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
Michael Meskes 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 there any other p
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, M
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 mo
Tom Lane írta:
> Boszormenyi Zoltan 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
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
>>> id
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 inconsiste
Tom Lane írta:
> Boszormenyi Zoltan 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
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
>
Boszormenyi Zoltan 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 BACKWARD
> witho
Tom Lane írta:
> Boszormenyi Zoltan 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 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.
>> A
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 c
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 f
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
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]:
Tom Lane írta:
> Michael Meskes 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 t
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
Michael Meskes 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 changes way smalle
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 í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
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
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 shou
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:
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. :-
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 copyright/lice
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
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 c
Tom Lane írta:
> Boszormenyi Zoltan 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 bit more
Boszormenyi Zoltan 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 subscription:
http
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.
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. dy
40 matches
Mail list logo
