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: pgsql-hackers@lists.postgresql.org
Date: 2020-03-02T22:52:17Z
Lists: pgsql-hackers
Attachments
- macros-for-alignment-and-storage-constants-1.patch (text/x-diff) patch
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
Commits
-
Introduce macros for typalign and typstorage constants.
- 3ed2005ff595 13.0 landed