|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>|
|Cc:||Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Joerg Sonnenberger <joerg(at)bec(dot)de>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> writes:
> On Wed, Jan 9, 2019 at 5:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> really need here. We could go with "[no-]case-insensitive", perhaps.
>> Or "[no-]case-fold", which is at least a little shorter and less
> I'd be in favor of --[no-]case-fold.
Yeah, I like that better too; I've been having to stop and think
every time as to which direction is which with the [in]sensitive
terminology. I'll make it "case-fold" throughout.
> This comment in PerfectHash.pm:
> (It does change '_', else we could just skip adjusting
> # $cn here at all, for typical keyword strings.)
> ...seems a bit out of place in the module, because of its reference to
> keywords, of interest right now to its only caller. Maybe a bit of
> context here. (I also don't quite understand why we could
> hypothetically skip the adjustment.)
Were it not for the underscore case, we could plausibly assume that
the supplied keywords are already all-lower-case and don't need any
further folding. But I agree that this comment is probably more
confusing than helpful; it's easier just to see that the code is
applying the same transform as the runtime lookup will do.
> Lastly, the keyword headers still have a dire warning about ASCII
> order and binary search. Those could be softened to match the comment
> in gen_keywordlist.pl.
Agreed, will do.
Thanks for reviewing!
regards, tom lane
|Next Message||Masahiko Sawada||2019-01-10 00:34:00||Re: A few new options for vacuumdb|
|Previous Message||John Naylor||2019-01-09 23:25:26||Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)|