RE: SQL statement PREPARE does not work in ECPG

From: "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>
To: "Takahashi, Ryohei" <r(dot)takahashi_2(at)jp(dot)fujitsu(dot)com>, 'Michael Meskes' <meskes(at)postgresql(dot)org>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: SQL statement PREPARE does not work in ECPG
Date: 2019-02-20 10:40:26
Message-ID: 03040DFF97E6E54E88D3BFEE5F5480F737AA826E@G01JPEXMBYT04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Maybe, there is no work-around.

For supporting it, there are two steps.
step1. fix for PREPARE.
step2. fix for EXECUTE.

About step1, there are two way.
I want to choose Idea-2.

Idea-1.
ecpglib prepares Oids of type listed in PREPARE statement for 5th argument of PQprepare().
But it's difficult because ecpg has to know Oids of type.
# Just an idea, create an Oid list in parsing.

Idea-2.
Use ECPGdo with whole PREPARE statement. In this way, there is no problem about Oid type because backend resolves it.
I think the current implementation may aim to it.

If we choose Idea-2, we should make a valid SQL-command(remove double quotation) and avoid any processing about prep_type_clause and PreparableStmt except for parsing.
One of such processing is the checking a number of parameters that occured the error.
It may take time, but it's easier than Idea-1.

Is the direction of fixing good?

About step2, there is the work-arround pointed by Meskes-san.

Regards
Ryo Matsumura

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleksii Kliukin 2019-02-20 10:50:42 Re: Prepared transaction releasing locks before deregistering its GID
Previous Message Peter Eisentraut 2019-02-20 10:22:23 Re: [HACKERS] Time to change pg_regress diffs to unified by default?