Re: hiding variable-length fields from Form_pg_* structs
От | Tom Lane |
---|---|
Тема | Re: hiding variable-length fields from Form_pg_* structs |
Дата | |
Msg-id | 2627.1323114450@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: hiding variable-length fields from Form_pg_* structs (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: hiding variable-length fields from Form_pg_* structs
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.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
В списке pgsql-hackers по дате отправления: