Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2012-01-26 Thread Peter Eisentraut
On mån, 2012-01-09 at 14:04 -0500, Tom Lane wrote: #ifdef CATALOG_VARLEN /* variable-length fields start here */ to be even clearer. What would be appropriate to add instead of those inconsistently-used comments is explicit comments about the exception cases such as

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2012-01-26 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: On mån, 2012-01-09 at 14:04 -0500, Tom Lane wrote: #ifdef CATALOG_VARLEN /* variable-length fields start here */ to be even clearer. What would be appropriate to add instead of those inconsistently-used comments is explicit comments

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2012-01-09 Thread Peter Eisentraut
So here is a patch for that. There are a few cases that break when hiding all variable length fields: Access to indclass in relcache.c, as discussed upthread, which should be fixed. Access to pg_largeobject.data. This is apparently OK, per comment in inv_api.c. Access to pg_proc.proargtypes

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2012-01-09 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: So I think the relcache.c thing should be fixed and then this might be good to go. Cosmetic gripes: I think we could get rid of the various comments that say things like variable length fields start here, since the #ifdef CATALOG_VARLEN lines now

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2011-12-05 Thread Peter Eisentraut
On sön, 2011-11-27 at 18:20 -0500, Tom Lane wrote: The low-tech way would be CATALOG(pg_attribute,1249) BKI_BOOTSTRAP ... { ... int4attinhcount; Oid attcollation; aclitem attacl[1]; #ifdef CATALOG_VARLEN_FIELDS textattoptions[1]; text

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2011-12-05 Thread Tom Lane
Peter Eisentraut pete...@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

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2011-12-05 Thread Robert Haas
On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@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

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2011-12-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@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?

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2011-12-05 Thread Robert Haas
On Mon, Dec 5, 2011 at 3:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: To clarify, I believe the rule is that the first variable-length field can

[HACKERS] hiding variable-length fields from Form_pg_* structs

2011-11-27 Thread Peter Eisentraut
It would be helpful if variable length catalog fields (except the first one) would not be visible on the C level in the Form_pg_* structs. We keep them listed in the include/catalog/pg_*.h files so that the BKI generating code can see them and for general documentation, but the fields are

Re: [HACKERS] hiding variable-length fields from Form_pg_* structs

2011-11-27 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: CATALOG(pg_attribute,1249) BKI_BOOTSTRAP ... { ... int4attinhcount; Oid attcollation; aclitem attacl[1]; CATVARLEN( textattoptions[1]; textattfdwoptions[1]; ) } FormData_pg_attribute;