tydedef extraction - back to the future
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:t49664psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 12:12 PM.
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 t49664_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 t49664_1 && git checkout t49664_1Patchset v1 (message #1) is on t49664_1
Many years ago we in effect moved maintenance of the typedefs list for
pgindent into the buildfarm client. The reason was that there were a
number of typedefs that were platform dependent, so we wanted to have
coverage across a number of platforms to get a comprehensive list.
Lately, this has caused some dissatisfaction, with people wanting the
logic for this moved back into core code, among other reasons so we're
not reliant on one person - me - for changes. I share this
dissatisfaction. Indeed, IIRC the use of the buildfarm was originally
intended as something of a stopgap. Still, we do need to multi-platform
support.
Attached is an attempt to thread this needle. The core is a new perl
module that imports the current buildfarm client logic. The intention is
that once we have this, the buildfarm client will switch to using the
module (if found) rather than its own built-in logic. There is precedent
for this sort of arrangement (AdjustUpgrade.pm). Accompanying the new
module is a standalone perl script that uses the new module, and
replaces the current shell script (thus making it more portable).
One thing this is intended to provide for is getting typedefs for
non-core code such as third party extensions, which isn't entirely
difficult
(<https://adpgtech.blogspot.com/2015/05/running-pgindent-on-non-core-code-or.html>)
but it's not as easy as it should be either.
Comments welcome.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
Attached is an attempt to thread this needle. The core is a new perl
module that imports the current buildfarm client logic. The intention is
that once we have this, the buildfarm client will switch to using the
module (if found) rather than its own built-in logic. There is precedent
for this sort of arrangement (AdjustUpgrade.pm). Accompanying the new
module is a standalone perl script that uses the new module, and
replaces the current shell script (thus making it more portable).
Haven't read the code in detail, but +1 for concept. A couple of
minor quibbles:
* Why not call the wrapper script "find_typedefs"? Without the "s"
it seems rather confusing --- "which typedef is this supposed to
find, exactly?"
* The header comment for sub typedefs seems to have adequate detail
about what the arguments are, but that all ought to be propagated
into the --help output for the wrapper script. Right now you
couldn't figure out how to use the wrapper without reading the
underlying module.
regards, tom lane
On 20.05.24 23:11, Andrew Dunstan wrote:
Attached is an attempt to thread this needle. The core is a new perl
module that imports the current buildfarm client logic. The intention is
that once we have this, the buildfarm client will switch to using the
module (if found) rather than its own built-in logic. There is precedent
for this sort of arrangement (AdjustUpgrade.pm). Accompanying the new
module is a standalone perl script that uses the new module, and
replaces the current shell script (thus making it more portable).
It looks like this code could use a bit of work to modernize and clean
up cruft, such as
+ my $sep = $using_msvc ? ';' : ':';
This can be done with File::Spec.
+ next if $bin =~ m!bin/(ipcclean|pltcl_)!;
Those are long gone.
+ next if $bin =~ m!/postmaster.exe$!; # sometimes a
copy not a link
Also gone.
+ elsif ($using_osx)
+ {
+ # On OS X, we need to examine the .o filesUpdate the name.
+ # exclude ecpg/test, which pgindent does too
+ my $obj_wanted = sub {
+ /^.*\.o\z/s
+ && !($File::Find::name =~ m!/ecpg/test/!s)
+ && push(@testfiles, $File::Find::name);
+ };
+
+ File::Find::find($obj_wanted, $binloc);
+ }Not clear why this is specific to that platform.
Also, some instructions should be provided. It looks like this is meant
to be run on the installation tree? A README and/or a build target
would be good.
The code distinguishes between srcdir and bindir, but it's not clear
what the latter is. It rather looks like the installation prefix. Does
this code support out of tree builds? This should be cleared up.