Symbolic names for the values of typalign and typstorage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Symbolic names for the values of typalign and typstorage
Date: 2020-03-02 22:52:17
Message-ID: 16457.1583189537@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While looking at Tomas' ALTER TYPE patch, I got annoyed by the fact
that all of the backend writes constants of type alignment and type
storage values as literal characters, such as 'i' and 'x'. This is
not our style for most other "poor man's enum" catalog columns, and
it makes it really hard to grep for relevant code. Hence, attached
is a proposed patch to invent #define names for those values.

As is our custom for other similar catalog columns, I only used the
macros in C code. There are some references in SQL code too,
particularly in the regression tests, but the difficulty of replacing
symbolic references in SQL code seems more than it's worth to fix.

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). Part of the issue is that I used the TYPALIGN_XXX
macros in tupmacs.h, but did not #include pg_type.h there because
I was concerned about macro inclusion bloat. Plausible alternatives
to the way I did it here include

* just bite the bullet and #include pg_type.h in tupmacs.h;

* keep using the hard-coded values in tupmacs.h (with a comment
as to why);

* put the TYPALIGN_XXX #defines somewhere else (not clear where,
but there might be a case for postgres.h, since so much of the
backend has some interest in alignment).

Thoughts? Anybody want to say that this is more code churn
than it's worth?

regards, tom lane

Attachment Content-Type Size
macros-for-alignment-and-storage-constants-1.patch text/x-diff 92.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2020-03-02 23:12:46 Re: SQL/JSON: functions
Previous Message Nikita Glukhov 2020-03-02 22:33:57 Re: SQL/JSON: functions