Re: ECPG patch causes warning

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Meskes <meskes(at)postgresql(dot)org>
Subject: Re: ECPG patch causes warning
Date: 2010-01-13 07:51:43
Message-ID: 20100113075143.GA12837@feivel.credativ.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 10, 2010 at 07:16:59PM +0100, Boszormenyi Zoltan wrote:
> As would ecpg_dynamic_type(), then. :-(

My guess is that this function is fine when returning InvalidOid = 0. AFAICT it
is supposed to fill an integer with the SQL3 type code which seems to start
with 1 too. So I will change this one to return 0.

> Perhaps InvalidOid wouldn't be the best choice to return,
> because this function returns int, not Oid. InvalidOid equals
> to ECPGt_char. Hm... it would be hiding the failure in

No, ECPGt_char is set to 1.

> a good way, as the type returned couldn't be mapped to
> any ECPGt_* type, and the value would be returned in
> a string anyway. We can use ECPGt_char for the unhandled case.

The question is, do we want to catch the unhandled case or shall we assume a
string? Just tell me and I'll commit.

Looking at the usage of sqlda_dynamic_type again we would run into this
situation even earlier as the return value then is stort in a short int because
that's what the other sqlda deffinitions use too. Therefore we have to make
sure we do not cross the short max. I'm glad at least one compiler caught this.

Michael

--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes(at)jabber(dot)org
VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-01-13 08:05:35 Re: plpgsql: open for execute - add USING clause
Previous Message Jaime Casanova 2010-01-13 06:14:05 Re: lock_timeout GUC patch