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

David Rowley <dgrowleyml(at)gmail(dot)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