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