Hi Matsumura-san,
Thank you for your explaining.
> An important point of the route is that it calls PQprepare() and PQprepare()
> needs type-Oid list. (Idea-1) If we fix for Prepare statement with AS clause
> and
> with parameter list to walk through the route, preprocessor must parse the
> parameter list and
> preprocessor or ecpglib must make type-Oid list. I think it's difficult.
> Especially, I wonder if it can treat user defined type and complex structure
> type.
I agree.
In the case of standard types, ECPG can get oids from pg_type.h.
However, in the case of user defined types, ECPG needs to access pg_type table
and it is overhead.
Therefore, the second idea seems better.
By the way, should we support prepare statement like following?
(I think yes.)
============================
EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id = :ID or
id =$1;
============================
Current ECPG produces following code.
============================
ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "prepare \"test_prep\" ( int )
as \" select id from test_table where id = $1 or id = $1 \"",
ECPGt_int,&(ID),(long)1,(long)1,sizeof(int),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EOIT, ECPGt_EORT);
============================
In this case, both ":ID" and "$1" in the original statement are converted to
"$1" and ECPGdo() cannot distinguish them.
Therefore, ECPG should produce different code.
For example,
- ECPG convert ":ID" to "$1" and "$1" in the original statement to "$$1"
- next_insert() do not check "$$1"
- ECPGdo() reconvert "$$1" to "$1"
Regards,
Ryohei Takahashi
