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

Поиск
Список
Период
Сортировка
От Matsumura, Ryo
Тема RE: [PROPOSAL]a new data type 'bytea' for ECPG
Дата
Msg-id 03040DFF97E6E54E88D3BFEE5F5480F737A6D271@G01JPEXMBYT04
обсуждение исходный текст
Ответ на Re: [PROPOSAL]a new data type 'bytea' for ECPG  (Michael Meskes <meskes@postgresql.org>)
Ответы Re: [PROPOSAL]a new data type 'bytea' for ECPG  (Michael Meskes <meskes@postgresql.org>)
Список 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 по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: Introducing SNI in TLS handshake for SSL connections
Следующее
От: Andres Freund
Дата:
Сообщение: Computing the conflict xid for index page-level-vacuum on primary