Re: WIP: a way forward on bootstrap data

There still seems to be a lot of boilerplate in the .dat files
that could be eliminated. Tom mentioned upthread that he did
not want too much magic in genbki.pl or Catalog.pm, but I think
I can propose putting some magic in the header files themselves.

Take, for example, some of the fields in pg_type.dat. I'll elide
the ones I'm not talking about with ...:

{... typname => 'X', ... typinput => 'Xin', typoutput => 'Xout',
typreceive => 'Xrecv', typsend => 'Xsend', ... },

If we changed pg_type.h:

/* text format (required) */
- regproc typinput BKI_LOOKUP(pg_proc);
- regproc typoutput BKI_LOOKUP(pg_proc);
+ regproc typinput BKI_DEFAULT("${typname}in") BKI_LOOKUP(pg_proc);
+ regproc typoutput BKI_DEFAULT("${typname}out") BKI_LOOKUP(pg_proc);

/* binary format (optional) */
- regproc typreceive BKI_LOOKUP(pg_proc);
- regproc typsend BKI_LOOKUP(pg_proc);
+ regproc typreceive BKI_DEFAULT("${typname}recv") BKI_LOOKUP(pg_proc);
+ regproc typsend BKI_DEFAULT("${typname}send") BKI_LOOKUP(pg_proc);

we could remove the typinput, typoutput, typreceive, and typsend
fields from many of the records. The logic for how to derive these
fields would not be hardcoded into genbki.pl or Catalog.pm, but rather
would be in pg_type.h, where it belongs. The pattern "${typname}in",
for example, is not hardcoded in perl, but is rather specified
in pg_type.h, making it obvious for those reading pg_type.h what the
pattern will be for generating the default value.

For those types where the typreceive and/or typsend values are not defined,
owing to receive and send functionality not being implemented, the user
would need to specify something like:

{... typname => 'X', typreceive => '-', typsend => '-'},

but that seems desirable anyway, as it helps to document the lacking
functionality. For types with associated functions named 'X_in', 'X_out',
'X_recv' and 'X_send' rather than 'Xin', 'Xout', 'Xrecv' and 'Xsend'
the user would have to specify those function names. That's not a
regression from how things are now, as all function names are currently
required. Perhaps after this change is applied (if it is) there will be
some pressure to standardize the naming of these functions. I'd consider
that a good thing.

If we changed pg_proc.h:

/* procedure source text */
- text prosrc BKI_FORCE_NOT_NULL;
+ text prosrc BKI_DEFAULT("${proname}") BKI_FORCE_NOT_NULL;

we could remove the prosrc field from many of the records, which would
do a better job of calling attention to the remaining records where the
C function name differs from the SQL function name.

These two changes have been made in the patch I am submitting, with the
consequence that pg_type.dat drops from 52954 bytes to 49106 bytes, and
pg_proc.dat drops from 521302 bytes to 464554 bytes. Since postgres.bki
is unchanged, I don't mean to suggest any runtime or initdb time performance
improvement; I only mention the size reduction to emphasize that there
is less text for human programmers to review.

There are further changes possible along these lines, where instead of
specifying s/FOO/BAR/ type substitition, we have something more like
s/FOO/BAR/e and s/FOO/BAR/ee type symantics, but before proposing
them, I'd like to see if the community likes the direction I am going
with this patch. If so, we can debate whether, for example, the default
alignment requirements of a type can be derived from the type's size
rather than having to be specified for every row in pg_type.dat.

mark