Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

John Naylor <jcnaylor(at)gmail(dot)com> writes:
> On 12/27/18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> +$kw_input_file =~ /((\w*)kwlist)\.h/;
>> +my $base_filename = $1;
>> +$prefix = $2 if !defined $prefix;
>>
>> Hmm, what happens if the input filename does not end with "kwlist.h"?

> If that's a maintainability hazard, I can force every invocation to
> provide a prefix instead.

I don't mind allowing the prefix to default to empty. What I was
concerned about was that base_filename could end up undefined.
Probably the thing to do is to generate base_filename separately,
say by stripping any initial ".*/" sequence and then substitute
'_' for '.'.

>> I looked very briefly at v4-0002, and I'm not very convinced about
>> the "middle" aspect of that optimization. It seems unmaintainable,
>> plus you've not exhibited how the preferred keywords would get selected
>> in the first place (wiring them into the Perl script is surely not
>> acceptable).

> What if the second argument of the macro held this info?

Yeah, you'd have to do something like that. But I'm still concerned
about the maintainability aspect: if we mark say "commit" as the
starting point in the "c" group, future additions or deletions of
keywords starting with "c" might render that an increasingly poor
choice. But most likely nobody would ever notice that the marking
was getting more and more suboptimal.

regards, tom lane