RE: [PROPOSAL]a new data type 'bytea' for ECPG - Mailing list pgsql-hackers

Meskes-san

> 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.

I agree that the special route is ugly, but I cannot remove them completely.
I try to implement Idea-2. In same time, I try to move if(bytea) blocks to
new function for readability.

e.g. move the following to new function set_data_attr().

 if (var->type != ECPGt_bytea)
      desc_item->is_binary = false;
  else
  {
      struct ECPGgeneric_varchar *variable =
      (struct ECPGgeneric_varchar *) (var->value);
      desc_item->is_binary = true;
      desc_item->data_len = variable->len;
  }
  ecpg_free(desc_item->data);
  desc_item->data = (char *) tobeinserted;

Regards
Ryo Matsumura

> -----Original Message-----
> From: Michael Meskes [mailto:meskes@postgresql.org]
> Sent: Wednesday, February 13, 2019 9:09 PM
> To: Matsumura, Ryo/松村 量 <matsumura.ryo@jp.fujitsu.com>
> Cc: Tsunakawa, Takayuki/綱川 貴之 <tsunakawa.takay@jp.fujitsu.com>;
> pgsql-hackers@lists.postgresql.org
> Subject: 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
> 
>