Re: hiding variable-length fields from Form_pg_* structs

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> To clarify, I believe the rule is that the first variable-length field
> can be accessed as a struct field. Are there any exceptions to this?

If it is known not null, yes, but I wonder just how many places actually
depend on that. It might be better to remove all varlena fields from C
visibility and require use of the accessor functions. We should at
least look into what that would cost us.

> Also, this code in relcache.c accesses indclass, which is after an
> int2vector and an oidvector field:

> /* Check to see if it is a unique, non-partial btree index on OID */
> if (index->indnatts == 1 &&
> index->indisunique && index->indimmediate &&
> index->indkey.values[0] == ObjectIdAttributeNumber &&
> index->indclass.values[0] == OID_BTREE_OPS_OID &&
> heap_attisnull(htup, Anum_pg_index_indpred))
> oidIndex = index->indexrelid;

Hmm, that does look mighty broken, doesn't it ... but somehow it works,
else GetNewOid would be bleating all the time. (Thinks about that for
a bit) Oh, it accidentally fails to fail because the C declarations
for int2vector and oidvector are actually correct if there is a single
element in the arrays, which we already verified with the indnatts test.
But yeah, this seems horribly fragile, and it should not be performance
critical because we only go through here when loading up a cache entry.
So let's change it.

regards, tom lane