Re: Splitting up guc.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Splitting up guc.c
Date
Msg-id 925946.1662918775@sss.pgh.pa.us
Whole thread Raw
In response to Re: Splitting up guc.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Splitting up guc.c
List pgsql-hackers
I wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> One part that I have found a bit strange lately about guc.c is that we
>> have mix the core machinery with the SQL-callable parts.  What do you
>> think about the addition of a gucfuncs.c in src/backend/utils/adt/ to
>> split things a bit more?

> I might be wrong, but I think the SQL-callable stuff makes use
> of some APIs that are currently private in guc.c.  So we'd have
> to expose more API to make that possible.  Maybe that wouldn't
> be a bad thing, but it seems to be getting beyond the original
> idea here.

I tried this just to see, and it worked out better than I thought.
The key extra idea is to also pull out the functions implementing
the SET and SHOW commands, because (unsurprisingly) those are just
about in the same place dependency-wise as the SQL functions, and
they have some common subroutines.

I had to export get_config_unit_name(), config_enum_get_options(),
and _ShowOption() (here renamed to ShowGUCOption()) to make this
work.  That doesn't seem too awful.

v2 attached does this, without any further relocation of hook
functions as yet.  I now see these file sizes:

$ wc guc*c
  2629   9372  69467 guc-file.c
  6425  22282 176816 guc.c
  1048   3005  26962 guc_funcs.c
   939   2693  22915 guc_hooks.c
  4877  13163 126769 guc_tables.c
 15918  50515 422929 total
$ size guc*o
   text    data     bss     dec     hex filename
  13653       4     112   13769    35c9 guc-file.o
  46589       0     564   47153    b831 guc.o
   8509       0       0    8509    213d guc_funcs.o
   6951       0     112    7063    1b97 guc_hooks.o
  43570   62998     216  106784   1a120 guc_tables.o

So this removes just about a thousand more lines from guc.c,
which seems worth doing.

            regards, tom lane


Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: why can't a table be part of the same publication as its schema
Next
From: andrey.arapov@nixaid.com
Date:
Subject: Re: [PATCH] initdb: do not exit after warn_on_mount_point