On 2013-12-05 08:58:55 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > 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. > > No, you're failing to think about the context here.
Ah yes. I was completely forgetting that heap_form_tuple()/heap_fill_tuple() will properly take care to only use meaningful parts of the (to-be-)stored data, not random padding. Thanks. > The risk we take by simplifying comparisons in a more general context > is that some function somewhere might've been sloppy about doing a > native-type-to-Datum conversion on its result. In the case of V0 > functions that risk is unavoidable except by adding some explicit cleanup > code, but 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... 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
