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

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
>

In response to

Browse pgsql-hackers by date

  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