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 03040DFF97E6E54E88D3BFEE5F5480F737A6D271@G01JPEXMBYT04
Whole thread Raw
In response to Re: [PROPOSAL]a new data type 'bytea' for ECPG  (Michael Meskes <meskes@postgresql.org>)
Responses Re: [PROPOSAL]a new data type 'bytea' for ECPG  (Michael Meskes <meskes@postgresql.org>)
List pgsql-hackers
Meskes-san

> > > > The patch does not support ECPG.bytea in sqltype of "struct
> > > > sqlvar_struct"
> > > > because of compatibility.
> > 
> > Sorry I do not really understand what you mean. Could you please
> > explain?
> 
> I meaned that existing applications that receive data of bytea column
> with using sqlda will encounter their unknown type(=ECPG.bytea) in
> sqlvar_struct.sqltype.
> 
> You mean if they are not recompiled? If so, yes, how else could that be
> handled?

Even if they are recompiled, they will fail.

  switch (sqlvar_struct.sqltype)
  {
    case ECPG.int:  break;
    case ECPG.char: break;
      /* There is no case for ECPG.bytea */
    default:  abort();

There is an idea as following, but it seems to be ugly.

  Implement a parameter for ecpglib.
  The parameter means whether application want to receive
  bytea data in binary format or not. Default is "not".
  # I don't know any ecpglib's parameter like it.

In other words, if application uses "bytea" type host variable, 
ecpglib could know its intent, but in case of sqlda ecpglib could
not know it.

Regards
Ryo Matsumura

pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Introducing SNI in TLS handshake for SSL connections
Next
From: Andres Freund
Date:
Subject: Computing the conflict xid for index page-level-vacuum on primary