Re: 7.3beta and ecpg - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: 7.3beta and ecpg
Date
Msg-id 20020911124349.GE1648@feivel.fam-meskes.de
Whole thread Raw
In response to Re: 7.3beta and ecpg  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
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!


pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: problem with new autocommit config parameter and jdbc
Next
From: Stephan Szabo
Date:
Subject: Re: problem with new autocommit config parameter and jdbc