On 2013-12-04 18:48:44 -0500, Robert Haas wrote: > * When a type narrower than Datum is stored in a Datum, we place it in the > * low-order bits and are careful that the DatumGetXXX macro for it discards > * the unused high-order bits (as opposed to, say, assuming they are zero). > * This is needed to support old-style user-defined functions, since depending > * on architecture and compiler, the return value of a function returning char > * or short may contain garbage when called as if it returned Datum. > > And record_image_eq does a rather elaborate dance around here, calling > the appropriate GET_x_BYTES macro depending on the type-width. If we > can really count on the high-order bits to be zero, that's all > completely unnecessary tomfoolery.
I don't think we can get rid of that dance in record_image_eq - it very well could used on records originally generated when those bits haven't been guaranteed to be zeroed. Other usecases where the appropriate DatumGetFoo() macros are used don't have a problem with that since it's cleared again there, but in record_image_eq we can't rely on that. Or am I missing something? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
