Re: Symbolic names for the values of typalign and typstorage
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-03-03T15:11:28Z
Lists: pgsql-hackers
I wrote: > Alvaro Herrera <alvherre@2ndquadrant.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
Commits
-
Introduce macros for typalign and typstorage constants.
- 3ed2005ff595 13.0 landed