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/