| From: | John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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) |
| Date: | 2019-01-09 23:25:26 |
| Message-ID: | CACPNZCvOpKnn6GS=U9WSW8dfwCF4EZ1U1AM8tNY_hk8gwOi27g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
> double-negative-y.
I'd be in favor of --[no-]case-fold.
On Tue, Jan 8, 2019 at 5:53 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I improved the comment about how come the hash table entry assignment
> works.
I've gone over the algorithm in more detail and I don't see any nicer
way to write it. 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.)
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.
--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-01-09 23:41:05 | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) |
| Previous Message | Andrew Dunstan | 2019-01-09 23:24:33 | Re: BUG #15446: Crash on ALTER TABLE |