Thread: [HACKERS] proposal: Support Unicode host variable in ECPG
Hello,
This is a new requirement comes from some customers hoping the ECPG can support Unicode host variable which can compatible with the same feature in Oracle Pro*C.
By using this Unicode data type, user can define Unicode variables in ECPG application in windows platform, save the content of the Unicode host variables into the database as database character set or get the content from the database into the Unicode host variables.
Requirements
============
1. support utext keyword in ECPG
The utext is used to define the Unicode host variable in ECPG application in windows platform.
2. support UVARCHAR keyword in ECPG
The UVARCHAR is used to define the Unicode vary length host variable in ECPG application in windows platform.
3. Saving the content of the Unicode variables into the database as database character set or getting the content from the database into the Unicode variables.
4. Firstly can only consider the UTF8 as database character set and UTF16 as the Unicode format for host variable. A datatype convert will be done between the UTF8 and UTF16 by ECPG.
5. Since Unicode has big-endian and little-endian format, a environment variable is used to identify them and do the endianness convert accordingly.
Usage
============
int main() {
EXEC SQL BEGIN DECLARE SECTION;
utext employee[20] ; /* define Unicode host variable */
UVARCHAR address[50] ; /* defin a vary length Unicode host variable */
EXEC SQL END DECLARE SECTION;
...
EXEC SQL CREATE TABLE emp (ename char(20), address varchar(50));
/* UTF8 is the database character set */
EXEC SQL INSERT INTO emp (ename) VALUES ('Mike', '1 sydney, NSW') ;
/* Database character set converted to Unicode */
EXEC SQL SELECT ename INTO :employee FROM emp ;
/* Database character set converted to Unicode */
EXEC SQL SELECT address INTO :address FROM emp ;
wprintf(L"employee name is %s\n",employee);
wprintf(L"employee address is %s\n", address.attr);
DELETE * FROM emp;
/* Unicode converted to Database character */
EXEC SQL INSERT INTO emp (ename,address) VALUES (:employee, :address);
EXEC SQL DROP TABLE emp;
EXEC SQL DISCONNECT ALL;
}
--
Regards,
Jing Wang
Fujitsu Australia
Hi,
I would like to provide the patch file that ECPG can support the utf16/utf32 unicode host variable type. This feature is used to compatible the same feature in Oracle's. Please find Oracle's feature in the [1].
Regards,
Jing Wang
Fujitsu Australia
Attachment
On Thu, Oct 26, 2017 at 12:29 PM, Jing Wang <jingwangian@gmail.com> wrote: > I would like to provide the patch file that ECPG can support the utf16/utf32 > unicode host variable type. This feature is used to compatible the same > feature in Oracle's. Please find Oracle's feature in the [1]. > > [1] https://docs.oracle.com/database/121/LNPCC/pc_05adv.htm#LNPCC3273 The core of the patch is roughly 800 lines, and it adds 20k lines of tests, which is large to digest. +PQGetEncodingFromPGres 173 +PQGetEncodingFromPGconn 174 +PQGetEncodingName 175 +PQGenEncodingMaxLen 176 This adds four undocumented APIs to libpq. And why not using client_encoding? The patch does not apply anymore and needs a rebase. There are also a bunch of whitespace errors, no documentation in the patch, and it seems to me that this patch introduces many concepts so it could be broken down into many individual steps. Finally, I strongly recommend that you review other's patches. You have two patches, including this one, registered into this commit fest but your name is showing nowhere as a reviewer. The patch you are proposing here is large, the usual recommendation being to review one patch of equal difficulty for each patch sent to keep the inflow and outflow of patches balanced. I am adding Michael Meskes to this thread, he is the maintainer of ECPG so perhaps he would be interested in what you have here. Thanks. -- Michael
On Tue, Nov 21, 2017 at 4:02 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > The patch does not apply anymore and needs a rebase. There are also a > bunch of whitespace errors, no documentation in the patch, and it > seems to me that this patch introduces many concepts so it could be > broken down into many individual steps. Finally, I strongly recommend > that you review other's patches. You have two patches, including this > one, registered into this commit fest but your name is showing nowhere > as a reviewer. The patch you are proposing here is large, the usual > recommendation being to review one patch of equal difficulty for each > patch sent to keep the inflow and outflow of patches balanced. With a high-level look, this patch requires a bit more work.. I am unsure as well if that's a feature which would prove to be useful, but without documentation it is hard to make an opinion of it. I am marking the patch as returned with feedback. -- Michael