Re: [HACKERS] 7.3beta and ecpg
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 [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.3beta and ecpg
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 [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3beta and ecpg
Michael Meskes [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3beta and ecpg
On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote: Michael Meskes [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [HACKERS] 7.3beta and ecpg
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 [EMAIL PROTECTED] 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
Re: [HACKERS] 7.3beta and ecpg
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 [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3beta and ecpg
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 [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.3beta and ecpg
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3beta and ecpg
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 [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3beta and ecpg
Michael Meskes [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.3beta and ecpg
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 use the 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 prepared statements where you don't directly use host variables in the statement, but placeholders (?). 4. we did use the 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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. --- 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3beta and ecpg
Dann Corbit wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.3beta and ecpg
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3beta and ecpg
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] 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? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.3beta and ecpg
Tom Lane dijo: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3beta and ecpg
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3beta and ecpg
Michael Meskes [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3beta and ecpg
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 [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.3beta and ecpg
Tom Lane wrote: Michael Meskes [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
