Hi all and thank you Matsumura-san.
> Excuse:
> It doesn't include regression tests and pass them.
> Because I must reset all expected C program of regression.
> # I add an argument to ECPGdo().
Sure, let's do this at the very end.
> 1. Specification
> It accepts the following .pgc.
> I confirmed it works well for AT clause.
> All results for st1 and st2 are same.
I have a similar text case and can confirm that the output is the same
for both ways of preparing the statement.
> 2. Behavior of ecpglib
> (1) PREPARE with AS clause
> Ecpglib sends the PREPARE statement to backend as is. (using
> PQexec).
>
> (2) EXECUTE with parameter list
> Ecpglib sends the EXECUTE statement as is (using PQexec), but all
> host variables in
> the list are converted to string-formatted and embedded into the
> EXECUTE statement.
>
> (3) PREPARE with FROM clause (not changed)
> Ecpglib sends 'P' libpq-message with statement (using PQprepare).
>
> (4) EXECUTE without parameter list (not changed)
> Ecpglib sends 'B' libpq-message with parameters. (using
> PQexecPrepared).
>
>
> 3. Change of preprocessor
>
> - I add ECPGst_prepare and ECPGst_execnormal.
> ECPGst_prepare is only for (1) and ECPGst_execnormal is only for
> (2).
> # I think the names are not good.
>
> - I add one argument to ECPGdo().p It's for prepared statement name.
One question though, why is the statement name always quoted? Do we
really need that? Seems to be more of a hassle than and advantage.
> 4.
> I wonder whether I should merge (3) to (1) and (4) to (4) or not.
I would prefer to merge as much as possible, as I am afraid that if we
do not merge the approaches, we will run into issues later. There was a
reason why we added PQprepare, but I do not remember it from the top of
my head. Need to check when I'm online again.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
