RE: [PROPOSAL]a new data type 'bytea' for ECPG - Mailing list pgsql-hackers

From Matsumura, Ryo
Subject RE: [PROPOSAL]a new data type 'bytea' for ECPG
Date
Msg-id 03040DFF97E6E54E88D3BFEE5F5480F737A3316F@G01JPEXMBYT04
Whole thread Raw
In response to Re: [PROPOSAL]a new data type 'bytea' for ECPG  (Michael Meskes <meskes@postgresql.org>)
List 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@postgresql.org]
> Sent: Saturday, October 27, 2018 3:43 AM
> To: Matsumura, Ryo/松村 量 <matsumura.ryo@jp.fujitsu.com>;
> pgsql-hackers@lists.postgresql.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
> 


pgsql-hackers by date:

Previous
From: "Iwata, Aya"
Date:
Subject: RE: libpq debug log
Next
From: Krzysztof Nienartowicz
Date:
Subject: Re: Speeding up INSERTs and UPDATEs to partitioned tables