Re: Symbolic names for the values of typalign and typstorage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Symbolic names for the values of typalign and typstorage
Date: 2020-03-03 03:22:04
Message-ID: 5063.1583205724@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2020-Mar-02, Tom Lane wrote:
>> One thing that I'm not totally happy about, as this stands, is that
>> we have to #include "catalog/pg_type.h" in various places we did
>> not need to before (although only a fraction of the files I touched
>> need that).

> If we think that pg_type.h is the header to handle access to the pg_type
> catalog, then I would think that the function declarations at the bottom
> should be in some "internal" header file; then we can get rid of most
> the #includes in pg_type.h.

Well, aside from indirect inclusions, pg_type.h also brings in a bunch
of type OID macros, which I feel we don't want to broadcast everywhere.

One argument in favor of sticking these new macros somewhere "more
central" is that they apply to both pg_type and pg_attribute (that
is, attalign and attstorage also use them). That's not a strong
argument, maybe, but it's something.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Bandy 2020-03-03 03:23:37 Re: [PATCH] Documentation bug related to client authentication using TLS certificate
Previous Message Dilip Kumar 2020-03-03 03:12:52 Re: Fastpath while arranging the changes in LSN order in logical decoding