catalog files simplification
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t40764psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 04:07 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t40764_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t40764_1 && git checkout t40764_1Patchset v1 (message #1) is on t40764_1
The current catalog files all do this:
CATALOG(pg_aggregate,2600,AggregateRelationId)
{
...
} FormData_pg_aggregate;
typedef FormData_pg_aggregate *Form_pg_aggregate;
The bottom part of this seems redundant. With the attached patch, we
can generate that automatically, so this becomes just
CATALOG(pg_aggregate,2600,AggregateRelationId)
{
...
};
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Jun 12, 2019 at 7:52 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
The current catalog files all do this:
CATALOG(pg_aggregate,2600,AggregateRelationId)
{
...
} FormData_pg_aggregate;typedef FormData_pg_aggregate *Form_pg_aggregate;
The bottom part of this seems redundant. With the attached patch, we
can generate that automatically, so this becomes justCATALOG(pg_aggregate,2600,AggregateRelationId)
{
...
};
Maybe the macro definition could be split across several lines instead
of having one really long line?
Are some compilers going to be sad about typedef struct x x; preceding
any declaration or definition of struct x?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Jun 12, 2019 at 7:52 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:The current catalog files all do this:
CATALOG(pg_aggregate,2600,AggregateRelationId)
{
...
} FormData_pg_aggregate;typedef FormData_pg_aggregate *Form_pg_aggregate;
The bottom part of this seems redundant. With the attached patch, we
can generate that automatically, so this becomes justCATALOG(pg_aggregate,2600,AggregateRelationId)
{
...
};
Maybe the macro definition could be split across several lines instead
of having one really long line?
I think that would complicate Catalog.pm; not clear if it's worth it.
Are some compilers going to be sad about typedef struct x x; preceding
any declaration or definition of struct x?
Nope, we have lots of instances of that already, cf "opaque struct"
declarations in various headers.
A bigger objection might be that this would leave us with no obvious-
to-the-untrained-eye declaration point for either the struct name or
the two typedef names. That might make tools like ctags sad. Perhaps
it's not really any worse than today, but it bears investigation.
We should also check whether pgindent has any issue with this layout.
regards, tom lane
I wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Maybe the macro definition could be split across several lines instead
of having one really long line?
I think that would complicate Catalog.pm; not clear if it's worth it.
Oh, cancel that --- in an uncaffeinated moment, I thought you were asking
about splitting the *call* sites of the CATALOG() macro. I agree that
the *definition* could be laid out better than it is here.
regards, tom lane
On 2019-06-12 15:34, Tom Lane wrote:
A bigger objection might be that this would leave us with no obvious-
to-the-untrained-eye declaration point for either the struct name or
the two typedef names. That might make tools like ctags sad. Perhaps
it's not really any worse than today, but it bears investigation.
At least with GNU Global, it finds FormData_pg_foo but not Form_pg_foo.
But you can find the latter using grep. This patch would hide both of
those even from grep, so maybe it isn't a good idea then.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services