Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize

David Rowley <dgrowleyml@gmail.com> writes:
> I've attached another patch which uses another method to fix this, per
> an idea from Andres Freund.  I'd class it as a hack, but I don't have
> any better ideas aside from the mammoth task of making name variable
> length.  Indexes on name typed columns simply don't store all 64 bytes
> of the name, so it's not safe to have code that assumes a name Datum
> points to 64 bytes. The patch makes it so such a Datum *will* point to
> 64 bytes.  I've tried to do this as cheaply as possible by saving the
> indexes to name columns in a new array in IndexOnlyScanState.  That
> should make the overhead very small when indexes don't contain any
> name-typed columns.

I realize that this is just a draft patch, but the near-total lack
of comments is still disappointing.  Even at the draft stage,
good comments are important to make it reviewable.

I do not like testing "atttypid == NAMEOID" one bit.  As noted,
that will fail on domains over name.  It will also result in
unnecessary work when reading non-btree indexes that contain
name, since I don't think anything else has the same hack
that btree name_ops does (grep for cstring in pg_opclass.dat).
I think the correct thing is to see whether the index opclass
for the column is btree name_ops.  We don't seem to have an
oid_symbol macro for that, but it shouldn't be hard to add,
at least in HEAD.

            regards, tom lane