RE: SQL statement PREPARE does not work in ECPG

Поиск
Список
Период
Сортировка
От Matsumura, Ryo
Тема RE: SQL statement PREPARE does not work in ECPG
Дата
Msg-id 03040DFF97E6E54E88D3BFEE5F5480F737AA826E@G01JPEXMBYT04
обсуждение исходный текст
Ответ на RE: SQL statement PREPARE does not work in ECPG  ("Takahashi, Ryohei" <r.takahashi_2@jp.fujitsu.com>)
Ответы Re: SQL statement PREPARE does not work in ECPG  (Michael Meskes <meskes@postgresql.org>)
Список 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_clauseand 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Time to change pg_regress diffs to unified by default?
Следующее
От: Oleksii Kliukin
Дата:
Сообщение: Re: Prepared transaction releasing locks before deregistering its GID