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
Michael Meskes <[EMAIL PROTECTED]> 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 i
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 im
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
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 bette
> 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(...);
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. :
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 ex
> > 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/
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
PREPA
> 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 ,
> there is no way to distinguish them.
>
> I have no idea if there's a standard about exec
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 director
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
E
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
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 SQ
> -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 pl
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 a
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 p
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'
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
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.o
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
23 matches
Mail list logo
