Re: Generate GUC tables from .dat file - Mailing list pgsql-hackers

From John Naylor
Subject Re: Generate GUC tables from .dat file
Date
Msg-id CANWCAZai3Qmf_jnv2pv13AAz-ibBTVx7yuLLL6p8Y2ZBY_4o4Q@mail.gmail.com
Whole thread Raw
In response to Re: Generate GUC tables from .dat file  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On Wed, Aug 20, 2025 at 3:18 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> Ok, I did the big conversion, and tidied everything up so that it now
> generates the big tables in guc_tables.c from the .dat file.  This
> basically works now.

> - One thing I didn't reproduce in the generated code is the line breaks
> in the description strings.  But that should be ok either way.

It's certainly not worse than, say, some proargnames in pg_proc.dat.

> - In a few places there were complicated #ifdef's to determine the
> default value.  I extracted that out into separate symbols.

Seems fine this way.

> - I moved the C code comments into the .dat file as Perl comments.  I
> figure that makes sense as that's where people would be editing now.

That makes sense. I noticed some comments were not carried over. In a
mechanical change like this, I'd expect all comments to be preserved
in some form, or at least removed in the preparatory step so that the
change is more visible to others.

It'd probably take a bit of work to make format_dat_file.pl work with
non-catalog data. Maybe mechanical formatting is not so important here
because there is a smaller "schema", and less frequent change. Also, I
imagine we'd have more freedom to place perl comments if we know the
surroundings can't be shifted around.

--
John Naylor
Amazon Web Services



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: ReplicationSlotRelease() crashes when the instance is in the single user mode
Next
From: Yugo Nagata
Date:
Subject: Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION