Re: WIP: a way forward on bootstrap data

> On Apr 25, 2018, at 1:00 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
>> 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', ... },
>
> -1 for trying to automate this. It varies between fooin and foo_in,
> and it'll be annoying to have to remember which one happens
> automatically and which one needs an override.

That may be a good argument. I was on the fence about it, because I
like the idea that the project might do some cleanup and standardize
the names of all in/out/send/recv functions so that no overrides would
be required. (Likewise, I'd like the eq,ne,lt,le,gt,ge functions to
be named in a standard way.)

Would that be an API break and hence a non-starter?

>
>> 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.
>
> That one I kinda like.

Yeah, that one is simpler, and it is the one that makes the majority of
the difference in bringing down the size of the .dat files.

mark