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 15:11:28 |
Message-ID: | 1418.1583248288@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> 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.
I realized that a possible compromise position is to have tupmacs.h
include pg_type_d.h, not the whole pg_type.h header, thus dodging the
indirect inclusions. That still brings in the type-OID macros, but
it's a lot less header scope creep than I was first fearing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-03-03 15:24:59 | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
Previous Message | tushar | 2020-03-03 14:49:42 | Re: backup manifests |