From: | "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Michael Meskes' <meskes(at)postgresql(dot)org>, "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-10-30 09:46:48 |
Message-ID: | 03040DFF97E6E54E88D3BFEE5F5480F737A3316F@G01JPEXMBYT04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Michael
> > In Pro*C, the data should be represented as hex format C string.
>
> Just to clarify, there is no special datatype for binary data?
I apology for lack of research again.
Since it's a little difficult to answer, I explain by samples.
The following works.
unsigned char buffer[128]; /* It's not needed to declare in DECLARE section. */
exec sql var buffer is raw(128); /* This sematics may be different in ECPG. */
exec sql create table test(c1 raw(128));
exec sql insert into test(c1) values(:buffer);
The following cannot be pre-compiled.
In this sence, there is no special datatype for binary data.
exec sql begin declare section;
raw buffer[128]; /* error */
exec sql end declare section;
exec sql create table test(c1 raw(128));
exec sql insert into test(c1) values(:buffer);
> > bytea as a type of table definition may correspond to BLOB in the
> > standard.
>
> Would we prefer to add a blob datatype then?
I think that blob datatype is needed for large binary data *in finally*,
but blob datatype and its access methods(*) is not needed for non-large
binary data(e.g. use for text data of which encoding is different from
database encoding) because of its complexity.
My proposal is mainly for non-large binary data.
(*) e.g. In Pro*C, OPEN, READ, WRITE, CLOSE, APPEND, and so on.
> > It seems that there is no defact and no product following to the
> > standards.
> > I wonder whether bytea should follow to the standard completely or
> > follow to existing varchar for usability.
>
> Do you see any disadvantage of following the standard? I don't really
> see where the usability drawback is. In general I would prefer being as
> close to the standard as reasonably possible.
I think there is no special reason to follow to existing varchar.
I can accept the standard. (Re-implementation is not difficult.)
Thank you.
Regards
Ryo Matsumura
> -----Original Message-----
> From: Michael Meskes [mailto:meskes(at)postgresql(dot)org]
> Sent: Saturday, October 27, 2018 3:43 AM
> To: Matsumura, Ryo/松村 量 <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>;
> pgsql-hackers(at)lists(dot)postgresql(dot)org
> Subject: Re: [PROPOSAL]a new data type 'bytea' for ECPG
>
> Hi Ryo-san,
>
> > # Please call me Ryo. Matsumura is too long.
>
> Thanks.
>
> > In Pro*C, the data should be represented as hex format C string.
>
> Just to clarify, there is no special datatype for binary data?
>
> > bytea as a type of table definition may correspond to BLOB in the
> > standard.
>
> Would we prefer to add a blob datatype then?
>
> > It seems that there is no defact and no product following to the
> > standards.
> > I wonder whether bytea should follow to the standard completely or
> > follow to existing varchar for usability.
>
> Do you see any disadvantage of following the standard? I don't really
> see where the usability drawback is. In general I would prefer being as
> close to the standard as reasonably possible.
>
> Michael
> --
> Michael Meskes
> Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> Meskes at (Debian|Postgresql) dot Org
> Jabber: michael at xmpp dot meskes dot org
> VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
>
From | Date | Subject | |
---|---|---|---|
Next Message | Krzysztof Nienartowicz | 2018-10-30 09:54:06 | Re: Speeding up INSERTs and UPDATEs to partitioned tables |
Previous Message | Iwata, Aya | 2018-10-30 09:38:20 | RE: libpq debug log |