Re: Performance optimization of btree binary search

Andres Freund <andres(at)2ndquadrant(dot)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