From: | "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Michael Meskes' <meskes(at)postgresql(dot)org>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
Cc: | "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-12-14 01:42:19 |
Message-ID: | 03040DFF97E6E54E88D3BFEE5F5480F737A6D271@G01JPEXMBYT04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-12-14 01:42:35 | Computing the conflict xid for index page-level-vacuum on primary |
Previous Message | Chapman Flack | 2018-12-14 01:30:23 | Re: Introducing SNI in TLS handshake for SSL connections |