Re: 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/

Boszormenyi Zoltan <zb(at)cybertec(dot)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(at)cybertec(dot)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/

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(at)jabber(dot)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(at)jabber(dot)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/