Re: ECPG patch causes warning
От | Boszormenyi Zoltan |
---|---|
Тема | Re: ECPG patch causes warning |
Дата | |
Msg-id | 4B4D82C4.6090801@cybertec.at обсуждение исходный текст |
Ответ на | Re: ECPG patch causes warning (Michael Meskes <meskes@postgresql.org>) |
Ответы |
Re: ECPG patch causes warning
|
Список | pgsql-hackers |
Michael Meskes írta: > 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. > You're right. >> 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. > I think it's best to assume a string. ecpg_set_{compat,native}_sqlda() uses the defailt case in that meaning anyway. > 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 > > Thanks, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
В списке pgsql-hackers по дате отправления: