RE: [PROPOSAL]a new data type 'bytea' for ECPG

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

In response to

Responses

Browse pgsql-hackers by date

  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