Matsumura-san,
> > 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();
Sorry, I should have been more precise. I meant if they are not
recompiled against the new ecpglib which has a case for ECPG.bytea.
> 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.
I'm at a loss here. I don't understand what you are trying to say.
An incompatible change is ok if we change the version number of the
library accordingly.
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
