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@jabber.org
VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL