Andres Freund <and...@2ndquadrant.com> writes:
> On 2013-12-05 08:58:55 -0500, Tom Lane wrote:
>> I'm a bit worried that somebody, particularly third-party code,
>> might've sloppily written "return foo" in a V1 function when "return
>> Int32GetDatum(foo)" would be correct. In that case, the resultant Datum
>> might have not-per-spec high-order bits, and if it reaches the fast
>> comparator without ever having been squeezed into a physical tuple,
>> we've got a problem.
> Too bad V1 hasn't insisted on using PG_RETURN_* macros. That would have
> allowed asserts checking against such cases by setting
> fcinfo->has_returned = true or such...
[ shrug... ] PG_RETURN_DATUM has no practical way to verify that the
given Datum was constructed safely, so I think we'd just be adding
overhead with not much real safety gain.
In practice, if we were to change Datum to be a signed type (intptr_t
not uintptr_t), the most common cases would probably do the right thing
anyway, ie an int or short return value would get promoted to Datum
with sign-extension.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
