Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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 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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group