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: mes...@jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
