From: | "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, 'Michael Meskes' <meskes(at)postgresql(dot)org> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: [PROPOSAL]a new data type 'bytea' for ECPG |
Date: | 2018-11-12 02:14:58 |
Message-ID: | 03040DFF97E6E54E88D3BFEE5F5480F737A383FB@G01JPEXMBYT04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> From: Tsunakawa, Takayuki [mailto:tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com]
>
> I think the host variable data type that corresponds to the server-side bytea
> should be bytea. As the following pages state or imply, it would be better
> to create standard-compliant LOB types someday, and use the keyword BLOB in
> ECPG for that type. The server-side data types should have the names BLOB,
> CLOB and NCLOB. Those types should handle data larget than 1 GB and have the
> locator feature defined in the SQL standard. Maybe we should also advanced
> LOB features like Oracle's SecureFiles LOB and SQL Server's FileTables.
Tsunakawa-san, thanks for your advice.
I understand that C type definition of client-side bytea is not constrained by the standard BLOB.
What should I do next?
For now, I attach a patch that is removed noise(pgindent/typedef.list).
P.S.
The patch does not support ECPG.bytea in sqltype of "struct sqlvar_struct" because of compatibility.
Regards
Ryo Matsumura
Attachment | Content-Type | Size |
---|---|---|
ecpg_bytea_v1_1.patch | application/octet-stream | 62.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-11-12 02:47:27 | Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation |
Previous Message | chjischj@163.com | 2018-11-12 01:46:08 | Re:Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock |