Re: Performance optimization of btree binary search

On 2013-12-05 10:02:56 -0500, Tom Lane wrote:
> 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.

I was thinking of doing it for assert only anyway.

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

I was actually thinking about making Datum (and some other types we
have) structs or unions. Currently it's far, far to easy to mix them. We throw
away pretty much all of the little typesafety C has by typedef'ing them
to integral types with lots of autocasting behaviour.
Making Datum a union with all the base-types inside, would also get rid
of us violating the standard's aliasing rules...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services