Thread: 7.3beta and ecpg
Hi, I didn't download the beta but compared the CVS checkouts and it appears the ecpg directory is still the one from 7.2 not the one tagged big_bison. Will this one be moved into the mainstream source? Else we would be stuck with a non-compatible parser. If I shall move it, please tell me, I'm just not doing it before talking to you guys. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> I didn't download the beta but compared the CVS checkouts and it appears
> the ecpg directory is still the one from 7.2 not the one tagged
> big_bison. Will this one be moved into the mainstream source?
Well, I think we can't do that until postgresql.org has a version of
bison installed that will compile it. And I'm really hesitant to see us
depending on a beta version of bison. Any word on a new bison official
release?
We still have a few weeks until the situation gets critical, but maybe
it is time to start thinking about a fallback plan...
regards, tom lane
On Mon, Sep 09, 2002 at 09:38:39AM -0400, Tom Lane wrote: > Well, I think we can't do that until postgresql.org has a version of > bison installed that will compile it. And I'm really hesitant to see us > depending on a beta version of bison. Any word on a new bison official > release? No news yet. They just said "as soon as possible". :-) Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: > > I didn't download the beta but compared the CVS checkouts and it appears > > the ecpg directory is still the one from 7.2 not the one tagged > > big_bison. Will this one be moved into the mainstream source? > > Well, I think we can't do that until postgresql.org has a version of > bison installed that will compile it. And I'm really hesitant to see us > depending on a beta version of bison. Any word on a new bison official > release? > > We still have a few weeks until the situation gets critical, but maybe > it is time to start thinking about a fallback plan... IMHO, our fallback is to ship based on the bison beta. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
I think we should stop playing around with ecpg. Let's get the beta bison on postgresql.org and package the proper ecpg version for 7.3beta2. If we don't, we are going to get zero testing for 7.3 final. Marc? We will not find out if there are problems with the bison beta until we ship it as part of beta and I don't think we have to be scared of just because it is beta. --------------------------------------------------------------------------- Michael Meskes wrote: > Hi, > > I didn't download the beta but compared the CVS checkouts and it appears > the ecpg directory is still the one from 7.2 not the one tagged > big_bison. Will this one be moved into the mainstream source? Else we > would be stuck with a non-compatible parser. > > If I shall move it, please tell me, I'm just not doing it before talking > to you guys. > > Michael > -- > Michael Meskes > Michael@Fam-Meskes.De > Go SF 49ers! Go Rhein Fire! > Use Debian GNU/Linux! Use PostgreSQL! > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Dann Corbit wrote: > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: Tuesday, September 10, 2002 9:10 PM > > To: Michael Meskes > > Cc: PostgreSQL Hacker; Marc G. Fournier > > Subject: Re: [HACKERS] 7.3beta and ecpg > > > > > > > > I think we should stop playing around with ecpg. Let's get > > the beta bison on postgresql.org and package the proper ecpg > > version for 7.3beta2. If we don't, we are going to get zero > > testing for 7.3 final. > > > > Marc? > > > > We will not find out if there are problems with the bison > > beta until we ship it as part of beta and I don't think we > > have to be scared of just because it is beta. > > I have a dumb idea... > > Why not just package the output of the Bison beta version? > > It may not be comprehensible, but it does not need to be generated on > any particular target machine does it? > > Sure, it would be nice to be able to process the original grammar on any > client workstation. But if it will hold up the entire project, why not > just ship the preprocessed output? We do ship just the preprocessed output. We need the new bison on postgresql.org and we need the CVS to be updated for the new version and then beta2 will hold the proper bison output. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We will not find out if there are problems with the bison beta until we
> ship it as part of beta and I don't think we have to be scared of just
> because it is beta.
No? If there are bugs in it, they will break the main SQL parser, not
only ecpg. I am scared.
My idea of a reasonable fallback is to add prebuilt-with-the-beta-bison
output files to the ecpg directory, but not anyplace else. That is
ugly, but the effects of any bison problems will be limited to ecpg.
I am also still wondering if we couldn't tweak the grammar to eliminate
states so that ecpg would build with a standard bison. That would be a
win all 'round, but it requires effort that we maybe don't have to
spend.
regards, tom lane
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Tuesday, September 10, 2002 9:10 PM > To: Michael Meskes > Cc: PostgreSQL Hacker; Marc G. Fournier > Subject: Re: [HACKERS] 7.3beta and ecpg > > > > I think we should stop playing around with ecpg. Let's get > the beta bison on postgresql.org and package the proper ecpg > version for 7.3beta2. If we don't, we are going to get zero > testing for 7.3 final. > > Marc? > > We will not find out if there are problems with the bison > beta until we ship it as part of beta and I don't think we > have to be scared of just because it is beta. I have a dumb idea... Why not just package the output of the Bison beta version? It may not be comprehensible, but it does not need to be generated on any particular target machine does it? Sure, it would be nice to be able to process the original grammar on any client workstation. But if it will hold up the entire project, why not just ship the preprocessed output?
Tom Lane dijo: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > We will not find out if there are problems with the bison beta until we > > ship it as part of beta and I don't think we have to be scared of just > > because it is beta. > > No? If there are bugs in it, they will break the main SQL parser, not > only ecpg. I am scared. Just for the record: bison 1.49b reports lots of "invalid character" when processing plpgsql's grammar. However, the regression test passes. This is Linux/i686. $ make gram.c -C src/pl/plpgsql/src make: Entering directory `/home/alvherre/CVS/pgsql/src/pl/plpgsql/src' bison -y gram.y gram.y:101.24: invalid character: `,' gram.y:102.25: invalid character: `,' gram.y:104.26: invalid character: `,' gram.y:104.44: invalid character: `,' gram.y:106.24: invalid character: `,' gram.y:108.29: invalid character: `,' gram.y:108.46: invalid character: `,' gram.y:111.24: invalid character: `,' gram.y:112.22: invalid character: `,' gram.y:112.37: invalid character: `,' gram.y:117.25: invalid character: `,' gram.y:121.24: invalid character: `,' gram.y:121.36: invalid character: `,' gram.y:121.47: invalid character: `,' gram.y:122.23: invalid character: `,' gram.y:123.25: invalid character: `,' gram.y:123.34: invalid character: `,' gram.y:123.45: invalid character: `,' gram.y:123.57: invalid character: `,' gram.y:124.25: invalid character: `,' gram.y:124.43: invalid character: `,' gram.y:124.55: invalid character: `,' gram.y:125.23: invalid character: `,' gram.y:125.34: invalid character: `,' gram.y:125.47: invalid character: `,' gram.y:126.29: invalid character: `,' gram.y:126.43: invalid character: `,' gram.y:127.23: invalid character: `,' gram.y:127.35: invalid character: `,' gram.y:130.25: invalid character: `,' gram.y:134.26: invalid character: `,' -- Alvaro Herrera (<alvherre[a]atentus.com>) "El conflicto es el camino real hacia la union"
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > We will not find out if there are problems with the bison beta until we > > ship it as part of beta and I don't think we have to be scared of just > > because it is beta. > > No? If there are bugs in it, they will break the main SQL parser, not > only ecpg. I am scared. > > My idea of a reasonable fallback is to add prebuilt-with-the-beta-bison > output files to the ecpg directory, but not anyplace else. That is > ugly, but the effects of any bison problems will be limited to ecpg. Yes, I assumed we would use the new bison only for ecpg. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wed, Sep 11, 2002 at 12:45:06AM -0400, Tom Lane wrote: > No? If there are bugs in it, they will break the main SQL parser, not > only ecpg. I am scared. Actually there is one more problem. The backend introduced the EXECUTE command just recently. However, this clashes with the embedded SQL EXECUTE command. Since both may be called just with EXECUTE <name>, there is no way to distinguish them. I have no idea if there's a standard about execution of a plan but couldn't/shouldn't it be named "EXECUTE PLAN" instead of just "EXECUTE"? > I am also still wondering if we couldn't tweak the grammar to eliminate > states so that ecpg would build with a standard bison. That would be a > win all 'round, but it requires effort that we maybe don't have to > spend. Actually I think it will need quite some effort, in particular since I stay away from the backend grammar as much as possible. Once I change the backend compatible part of the grammar I either have to make the same changes to the backends parser or ecpg will soon be unmaintainable. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Wed, Sep 11, 2002 at 12:56:59AM -0400, Alvaro Herrera wrote: > Just for the record: bison 1.49b reports lots of "invalid character" > when processing plpgsql's grammar. However, the regression test passes. > This is Linux/i686. > > $ make gram.c -C src/pl/plpgsql/src > make: Entering directory `/home/alvherre/CVS/pgsql/src/pl/plpgsql/src' > bison -y gram.y > gram.y:101.24: invalid character: `,' No big deal. Just remove all the ','. The new bison does not like them as seperators anymore. We will have to make that change in the near future anyway. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
> Actually there is one more problem. The backend introduced the EXECUTE > command just recently. However, this clashes with the embedded SQL > EXECUTE command. Since both may be called just with EXECUTE <name>, > there is no way to distinguish them. > > I have no idea if there's a standard about execution of a plan but > couldn't/shouldn't it be named "EXECUTE PLAN" instead of just > "EXECUTE"? I know this is not really related, but wouldn't the plan be to make ecpg actually use the backend side "execute ..." now that it is available ? ecpg needs eighter 'execute :idvar' or 'execute id', so either idvar is a declared variable or id a statement id. I don't know if that is something a parser can check though :-( For now, I would leave "exec sql execute" do the ecpg thing if that is possible. If you want to use the backend side functionality you would need to: exec sql prepare ex1 from 'execute id'; exec sql execute ex1; Andreas
On Wed, Sep 11, 2002 at 11:23:45AM +0200, Zeugswetter Andreas SB SD wrote: > I know this is not really related, but wouldn't the plan be to make > ecpg actually use the backend side "execute ..." now that it is available ? Maybe I misunderstood something. Do you mean I could use the backend PREPARE/EXECUTE to prepare and execute any statement I can PREPARE/EXECUTE with the ecpg part? Can I use PREPARE to prepare a cursor? In that case I will gladly remove the ecpg stuff. I just looked into the backend any further and wonder why I didn't understand earlier. For some reason I was believing this was just an optimization command. It seems I can use larger parts of this thus reducing ecpg parser's complexity as well. > ecpg needs eighter 'execute :idvar' or 'execute id', so either idvar is a > declared variable or id a statement id. I don't know if that is something a > parser can check though :-( Actually ecpg needs 'execute id using ... into ...'. I did not see any mention of using in the backend execute command. The 'execute :idvar' part is easier since this correctly is named 'execute immediate :idvar' I think. AFAIK the standard is "execute ID using value" and not "execute ID(value)". Please correct me if I'm wrong, but right now ecpg uses the first syntax the backend uses the second. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
> > I know this is not really related, but wouldn't the plan be to make > > ecpg actually use the backend side "execute ..." now that it is available ? > > Maybe I misunderstood something. Do you mean I could use the backend > PREPARE/EXECUTE to prepare and execute any statement I can > PREPARE/EXECUTE with the ecpg part? Can I use PREPARE to prepare a > cursor? In that case I will gladly remove the ecpg stuff. That is how I understood it so far. > I just looked into the backend any further and wonder why I didn't > understand earlier. For some reason I was believing this was just an > optimization command. Well, yes and no. For programs the reuse a prepared statement it is good, for those that only use it once it can be a loss. Simple tests in prev posts to this list showed, that with longer data cstrings the parser was so slow, that prepare + execute actually sped up the overall exec time. (At least that was my interpretation) > > It seems I can use larger parts of this thus reducing ecpg parser's > complexity as well. Hopefully :-) > > > ecpg needs eighter 'execute :idvar' or 'execute id', so either idvar is a > > declared variable or id a statement id. I don't know if that is something a > > parser can check though :-( > > Actually ecpg needs 'execute id using ... into ...'. I did not see any > mention of using in the backend execute command. The 'execute :idvar' > part is easier since this correctly is named 'execute immediate :idvar' > I think. The "using" clause is optional, I just left it out. My ESQL/C precompiler can also use an id variable for "execute :idvar using ...". That is actually how we use esql/c here. > > AFAIK the standard is "execute ID using value" and not "execute > ID(value)". Please correct me if I'm wrong, but right now ecpg uses the > first syntax the backend uses the second. I think it should be the intention to keep those identical, which would mean, that the backend syntax is currently wrong :-( Andreas
On Wed, Sep 11, 2002 at 03:42:44PM +0200, Zeugswetter Andreas SB SD wrote: > That is how I understood it so far. I will dig into this as soon as I find time, i.e. definitely for 7.3. > > Actually ecpg needs 'execute id using ... into ...'. I did not see any > > mention of using in the backend execute command. The 'execute :idvar' > > part is easier since this correctly is named 'execute immediate :idvar' > > I think. > > The "using" clause is optional, I just left it out. My ESQL/C precompiler Correct, "using" is optional with ecpg as well. > can also use an id variable for "execute :idvar using ...". That is actually > how we use esql/c here. And how we used Pro*C when I was still working with Oracle. > > AFAIK the standard is "execute ID using value" and not "execute > > ID(value)". Please correct me if I'm wrong, but right now ecpg uses the > > first syntax the backend uses the second. > > I think it should be the intention to keep those identical, which would > mean, that the backend syntax is currently wrong :-( Which of course means we should change it. :-) Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes: > On Wed, Sep 11, 2002 at 03:42:44PM +0200, Zeugswetter Andreas SB SD wrote: >> I think it should be the intention to keep those identical, which would >> mean, that the backend syntax is currently wrong :-( > Which of course means we should change it. :-) IIRC, the conclusion of our earlier debate about backend PREPARE/EXECUTE syntax was that since it was not implementing exactly the behavior specified for embedded SQL (and couldn't, not being an embedded operation) it would be better to deliberately avoid using exactly the same syntax. See thread starting at http://archives.postgresql.org/pgsql-hackers/2002-07/msg00814.php We can revisit that decision if you like, but you must convince us that it was wrong, not just say "of course we should change it". regards, tom lane
> We can revisit that decision if you like, but you must convince us that
> it was wrong, not just say "of course we should change it".
I am sorry, but at that time I did not have time for the discussion,
and now is also very tight for me :-(
Four reasons I can give:1. execute xx(...); looks like xx is a procedure which it definitely is not.2. imho ecpg should
usethe backend side feature and thus the syntax should be the same. iirc the syntax was chosen to separate it from
esql,but if it gets to be the same why separate it ?3. I think a close comparison is possible for dynamically
preparedstatements where you don't directly use host variables in the statement, but placeholders ("?").4. we did
usethe esql standard for "declare cursor", why not now ?
Are the () mandatory for the backend side feature ? If yes, it would at least be possible
to differentiate ecpg from it.
Actually "exec sql execute" is only for statements not returning a result set (e.g. update).
selects would need 'declare "curid" cursor for ...' and fetch, but that would imho be an
improvement because you can then choose a named portal.
Andreas
On Wed, Sep 11, 2002 at 04:36:31PM -0400, Tom Lane wrote: > IIRC, the conclusion of our earlier debate about backend PREPARE/EXECUTE > syntax was that since it was not implementing exactly the behavior > specified for embedded SQL (and couldn't, not being an embedded > operation) it would be better to deliberately avoid using exactly the > same syntax. See thread starting at > http://archives.postgresql.org/pgsql-hackers/2002-07/msg00814.php I'm awfully sorry that I missed this thread. But I do not really understand the problem. If we cannot be exactly as specified why aren't we coming close? As it stands now I have to implement my own PREPARE/EXECUTE in ecpg and the syntax does clash with the backend one. This would force me to not allow the backend's prepare/execute at all in embedded sql but use the work around we've been using ever since. But the backend implementation certainly is better and faster, so I'd love to switch. > We can revisit that decision if you like, but you must convince us that > it was wrong, not just say "of course we should change it". Again, please take my apologies, since I missed the discussion. I'm so swarmed with work and emails that I have to delete some by just looking at the subject and appearantly I didn't see the relevance of this one. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> I'm awfully sorry that I missed this thread. But I do not really
> understand the problem. If we cannot be exactly as specified why aren't
> we coming close? As it stands now I have to implement my own
> PREPARE/EXECUTE in ecpg and the syntax does clash with the backend one.
But you must implement your own PREPARE/EXECUTE anyway, using ecpg
variables, no? If you can really embed what you need in the backend
facility, and only the syntax variation is getting in the way, then
maybe I misunderstand the problem. How do parameters of PREPAREd
statements work in ecpg?
regards, tom lane
On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: > > I'm awfully sorry that I missed this thread. But I do not really > > understand the problem. If we cannot be exactly as specified why aren't > > we coming close? As it stands now I have to implement my own > > PREPARE/EXECUTE in ecpg and the syntax does clash with the backend one. > > But you must implement your own PREPARE/EXECUTE anyway, using ecpg > variables, no? If you can really embed what you need in the backend > facility, and only the syntax variation is getting in the way, then > maybe I misunderstand the problem. How do parameters of PREPAREd > statements work in ecpg? In ecpg you can use a string variable or constant holding the statement to prepare that statement as in exec sql prepare STMT from string; This binds the ident STMT to the statement in string. Later you can then declare a cursor using exec sql declare CURS cursor for STMT; or execute the statement using exec sql execute STMT; Now if you have a parameter in the prepared statement by just specify "?" instead some value, you add a using clause during execution to set the values. I'm not sure where you expect the ecpg variables. If you're talking about C variables they won't be seen by any statement since ecpg creates an ascii string of the whole statement before sending it to the backend. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote:
>> But you must implement your own PREPARE/EXECUTE anyway, using ecpg
>> variables, no?
> In ecpg you can use a string variable or constant holding the statement
> to prepare that statement as in
> exec sql prepare STMT from string;
Sure --- and that is exactly *not* what the backend facility does. In
the backend PREPARE you supply the statement to be prepared directly in
the same SQL command, not as the value of some variable.
> Now if you have a parameter in the prepared statement by just specify
> "?" instead some value, you add a using clause during execution to set
> the values.
And a plain "?" isn't going to fly as the parameter marker, either.
The backend wants to know what datatype each parameter is supposed to
be.
regards, tom lane
On Thu, Sep 12, 2002 at 03:18:13PM -0400, Tom Lane wrote: > Sure --- and that is exactly *not* what the backend facility does. In > the backend PREPARE you supply the statement to be prepared directly in > the same SQL command, not as the value of some variable. The variable will be replaced by ecpg. That's not a problem. The actual ecpg prepare function does insert the value of the variable when storing the so-called prepared statement, which of course is not prepared in reality. > > Now if you have a parameter in the prepared statement by just specify > > "?" instead some value, you add a using clause during execution to set > > the values. > > And a plain "?" isn't going to fly as the parameter marker, either. > The backend wants to know what datatype each parameter is supposed to > be. So, yes, this may be a problem we have to think about. But I could handle that by asking the backend for the datatypes before issuing the PREPARE statement and thus formulating it accordingly. Anyway, we could of course keep both ways seperate, but right now that would mean I have to disable access to the backend functions in ecpg or else the parser will be in trouble or else the parser will be in trouble. And frankly I don't really like that. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!