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

Hi Michael

Thank you for your comment.

# Please call me Ryo. Matsumura is too long.

> > I think that set/put data for host variable should be more simple.
> > The following is an example of Oracle Pro *C program for RAW type
> > column.
> 
> Just to be clear, Oracle can use varchars for binary data, right?

I'm sorry. That is my mistake.
In Pro*C, the data should be represented as hex format C string.

> > In ECPG, varchar host variable cannot be used for bytea because it
> > cannot treat
> > '\0' as part of data. If the length is set to 10 and there is '\0' at
> > 3rd byte,
> > ecpglib truncates 3rd byte and later at the following:
> 
> I've been traveling too much to check, but does the standard say
> anything about that?

bytea as a type of table definition may correspond to BLOB in the standard.
If it is true, the standard defines corresponding type in C as the following:

  ------
  struct {
    long hvn_reserved
    unsigned long hvn_length
    char hvn_data[L];
  } hvn

  * hvn is the name of the host variable defined to correspond
    to the SQL data type
  ------

> > I also think that the behavior of varchar host variable should not be
> > changed
> > because of compatibility.
> > Therefore, a new type of host variable 'bytea' is needed.

> This I am actually not sure about. I think we should try to stick with
> the standard and, if it does not comment on it, with what others in the
> market do to make migrations easier. So far I do not remember any
> database having a bytea datatype in embedded SQL.

Maybe Oracle doesn't have it.
I found documents of DB2.

  blob(n) correspond to BLOB in V11.
  https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.apdv.embed.doc/doc/r0006090.html

  Since I don't have DB2 installation, I cannot confirm typedef of blob(n).
  But in V9 the following structure correspond to BLOB.
  https://www.ibm.com/support/knowledgecenter/en/SSEPGG_9.7.0/com.ibm.db2.luw.apdv.routines.doc/doc/c0009190.html

  struct sqludf_lob
  {
    sqluint32     length;      /* length in bytes */
    char          data[1];      /* first byte of lob */ 
  }; 

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.

Thank you.

Regards
Ryo Matsumura