Peter Eisentraut 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 abou
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
> proa
Peter Eisentraut 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 represent that in a
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 in
On Mon, Dec 5, 2011 at 3:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane wrote:
>>> Peter Eisentraut 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
Robert Haas writes:
> On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane wrote:
>> Peter Eisentraut 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 ju
On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane wrote:
> Peter Eisentraut 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 actuall
Peter Eisentraut 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 varl
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];
Peter Eisentraut writes:
> CATALOG(pg_attribute,1249) BKI_BOOTSTRAP ...
> {
> ...
> int4attinhcount;
> Oid attcollation;
> aclitem attacl[1];
> CATVARLEN(
> textattoptions[1];
> textattfdwoptions[1];
> )
> } FormData_pg_attribute;
> wher
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 meaningl
11 matches
Mail list logo
