On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote: [input functions aren't the only problematic source of uninitialized datum bytes]
> We've run into other manifestations of this issue before. Awhile ago > I made a push to ensure that datatype input functions didn't leave any > ill-defined padding bytes in their results, as a result of similar > misbehavior for simple constants. But this example shows that we'd > really have to enforce the rule of "no ill-defined bytes" for just about > every user-callable function's results, which is a pretty ugly prospect. FWIW, when I was running the test suite under valgrind, these were the functions that left uninitialized bytes in datums: array_recv, array_set, array_set_slice, array_map, construct_md_array, path_recv. If the test suite covers this well, we're not far off. (Actually, I only had the check in PageAddItem ... probably needed to be in one or two other places to catch as much as possible.) > The seemingly-obvious alternative is to teach equal() to use > type-specific comparison functions that will successfully ignore > semantically-insignificant bytes in a value's representation. However > this answer has got its own serious problems, including performance, > transaction safety (I don't think we can assume that equal() is always > called within live transactions) and the difficulty of identifying > suitable comparison functions. Not all types have btree comparison > functions, and for some of the ones that do, btree "equality" does not > imply that the values are indistinguishable for every purpose, which is > what we really need from equal(). Doesn't seem promising, indeed. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
