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
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? |