ECPG support for string pseudo-type
Hi,
in a continued effort for better Informix ESQL/C compatibility,
we added the "string" pseudo-type handling to ECPG.
This type in ESQL/C is documented as:
--------------------------------------------------
The string Data Type
The string data type is an ESQL/C data type that holds character data
that is
null terminated and does not contain trailing blanks. When an application
reads a value from a CHAR column into a host variable of data type
string, it
strips the value of any trailing blanks and appends a null terminator. The
behavior is the same if an application reads a value from a VARCHAR column
into a host variable of data type string.
Declare the string data type with a length of [n+1] (where n is the size
of the
column with values that you want read) to allow for the null terminator. Use
the following syntax to declare a host variable of the string data type:
EXEC SQL BEGIN DECLARE SECTION;
string str_name[n + 1];
EXEC SQL END DECLARE SECTION;
--------------------------------------------------
So, we added it accordingly. This means the following:
- "string" has become a type name, reserved word in ECPG.
- When ECPG encounters "string", it will be transparently replaced by
"char" in the generated C source, but ECPGt_string will be passed
to ECPGdo()
- ecpg_get_data() right-trims the string value if ECPGt_string was passed.
Two regression tests had to be modified because "string" is now
a type name: preproc/define.pgc and preproc/type.pgc.
The attached patch is built upon our previous patch supporting
dynamic cursor and SQLDA.
Best regards,
Zolt�n B�sz�rm�nyi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zolt�n B�sz�rm�nyi
Cybertec Sch�nig & Sch�nig GmbH
http://www.postgresql.at/
Attachments:
ecpg-string-8.4-1-ctxdiff.patchtext/x-patch; name=ecpg-string-8.4-1-ctxdiff.patchDownload+140-105
Boszormenyi Zoltan <zb@cybertec.at> writes:
in a continued effort for better Informix ESQL/C compatibility,
we added the "string" pseudo-type handling to ECPG.
...
- "string" has become a type name, reserved word in ECPG.
This seems like a sufficient reason to reject the patch. Who knows
what that will break? (I observe that it already broke a few of the
ecpg regression tests, suggesting that using "string" as a variable
name is hardly uncommon.)
regards, tom lane
Hi,
Tom Lane �rta:
Boszormenyi Zoltan <zb@cybertec.at> writes:
in a continued effort for better Informix ESQL/C compatibility,
we added the "string" pseudo-type handling to ECPG.
...
- "string" has become a type name, reserved word in ECPG.This seems like a sufficient reason to reject the patch. Who knows
what that will break? (I observe that it already broke a few of the
ecpg regression tests, suggesting that using "string" as a variable
name is hardly uncommon.)regards, tom lane
OK, let me retry. This version treats "string" as a non-reserved word,
and also discovers whether the PGC contains this construct below,
as in ecpg/tests/preproc/type.pgc:
exec sql type string is char[11];
typedef char string[11];
Now all regression tests pass unchanged and ECPG also accepts
string *string;
and
string string[N];
without typedef, replacing "string" with "char".
I think it's acceptable.
Thanks in advance,
Zolt�n B�sz�rm�nyi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zolt�n B�sz�rm�nyi
Cybertec Sch�nig & Sch�nig GmbH
http://www.postgresql.at/
Attachments:
ecpg-string-8.4-2-ctxdiff.patchtext/x-patch; name=ecpg-string-8.4-2-ctxdiff.patchDownload+89-15
On Sat, Jul 04, 2009 at 03:39:14PM +0200, Boszormenyi Zoltan wrote:
The attached patch is built upon our previous patch supporting
dynamic cursor and SQLDA.
Please don't do this unless the new patch relies on some changes made in the
older one.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
On Sat, Jul 04, 2009 at 05:09:04PM +0200, Boszormenyi Zoltan wrote:
OK, let me retry. This version treats "string" as a non-reserved word,
and also discovers whether the PGC contains this construct below,
as in ecpg/tests/preproc/type.pgc:exec sql type string is char[11];
typedef char string[11];
I don't like this because it means a datatype can change its meaning in the
middle of a source file. Your new datatype is only needed for Informix
compatibility, so why not only defining it when running in compatibility mode?
An Informix file will not have such a typedef because it wouldn't/shouldn't
work there either.
Also the new datatype needs some documentation.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes �rta:
On Sat, Jul 04, 2009 at 03:39:14PM +0200, Boszormenyi Zoltan wrote:
The attached patch is built upon our previous patch supporting
dynamic cursor and SQLDA.Please don't do this unless the new patch relies on some changes made in the
older one.Michael
AFAICS the only dependence is one small reject in ecpgtypes.h
because both patches add one new ECPGt_XXX constant.
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zolt�n B�sz�rm�nyi
Cybertec Sch�nig & Sch�nig GmbH
http://www.postgresql.at/
Michael Meskes �rta:
On Sat, Jul 04, 2009 at 05:09:04PM +0200, Boszormenyi Zoltan wrote:
OK, let me retry. This version treats "string" as a non-reserved word,
and also discovers whether the PGC contains this construct below,
as in ecpg/tests/preproc/type.pgc:exec sql type string is char[11];
typedef char string[11];I don't like this because it means a datatype can change its meaning in the
middle of a source file. Your new datatype is only needed for Informix
compatibility, so why not only defining it when running in compatibility mode?
An Informix file will not have such a typedef because it wouldn't/shouldn't
work there either.Also the new datatype needs some documentation.
Michael
Okay, I modified it so in Informix mode ECPG refuses
redefining the "string" type. I will add documentation and
also port it to 8.5devel, get_typedef() has changed since 8.4RC2
and it errors out now if asking for a non-typedef'd type name.
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zolt�n B�sz�rm�nyi
Cybertec Sch�nig & Sch�nig GmbH
http://www.postgresql.at/