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

Matsumura-san,

> Current architecture:
> Internal expression of varchar is C-string that includes length
> information implicitly
> because the length can be computed by strlen().
> ECPGdo(ecpg_build_params) assumes that the data in descriptor is C-
> string encoded.
>
> In other hand, bytea data is binary that doesn't include any length
> information.
> And the merit of my proposal is that bytea data can be sent to
> backend without
> C-string encodeing overhead. They are different points from varchar.

Yes, I agree with this. But it does not explain why we cannot just add
a length parameter. And it neither explains why we need so many if
(!bytea) { thisandthat } else { somethingelse } blocks. I would prefer
the integration to be smoother. Hopefully that is possible.

> My Idea-2 is that:
> - ECPGset_desc copies data to descriptor_item.data, set the length to
> dscriptor_item.data_len and set type information to
> descriptor_item.is_binary.
> - ecpg_build_params only memcpy as folowing without ecpg_store_input:
>
> if (descriptor_item.is_binary)
> memcpy(&tobeinserted, descriptor_item.data,
> descriptor_item.data_len)

Isn't that a better way then? This looks more smoothly to me.

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