Re: SQL statement PREPARE does not work in ECPG

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>, "Takahashi, Ryohei" <r(dot)takahashi_2(at)jp(dot)fujitsu(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Cc: "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, "Kuroda, Hayato" <kuroda(dot)hayato(at)jp(dot)fujitsu(dot)com>
Subject: Re: SQL statement PREPARE does not work in ECPG
Date: 2019-03-15 21:34:47
Message-ID: 6458a6907f5d4939a6fbc463482791f199741ab9.camel@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-03-15 21:41:47 Re: hyrax vs. RelationBuildPartitionDesc
Previous Message Michael Banck 2019-03-15 21:32:54 Re: REINDEX CONCURRENTLY 2.0