Re: ECPG patch causes warning

Tom Lane írta:
> Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
>
>> Tom Lane írta:
>>
>>> I think that the compiler has caught an actual mistake here.
>>>
>
>
>> Yes, it's a mistake, but not an actual bug.
>> The intent was to be able to catch unhandled
>> cases in the application, just as in ecpg_dynamic_type().
>> The fix for sqlda_dynamic_type() is to use the same cast:
>>
>
>
>> return -(int) type;
>>
>
>
>> Should I send a patch for this?
>>
>
> You should send a patch to *get rid of it*. Putting in a cast only
> hides the fact that this logic will break on OIDs above 2G.
>

As would ecpg_dynamic_type(), then. :-(

You wrote previously:
> Perhaps InvalidOid is the thing
> to use here?

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
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.

Another way (to lose only twenty-something values from 4GB)
would be to introduce ECPGt_max and
return (ECPGt_max + type)
to have mapping for a large amount of type Oids.
There would be a drawback in this case, when
a new type might get added to ECPG, and the value of
ECPGt_max changes. An Oid -> int mapping has the
advantage of being able to catch non-standard types,
but libecpg and the app may have different opinion about
the value of ECPGt_max, as the app may be compiled
against a different version of libecpg in a theoretical future.
I think that leaves the first choice.

Patch is attached.

Best regards,
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/