Hi, On 2018-12-20 00:54:39 +0000, Andrew Gierth wrote: > >>>>> "John" == John Naylor <jcnay...@gmail.com> writes: > > > On 12/18/18, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I'd be kind of inclined to convert all uses of ScanKeyword to the > >> new way, if only for consistency's sake. On the other hand, I'm not > >> the one volunteering to do the work. > > John> That's reasonable, as long as the design is nailed down first. > John> Along those lines, attached is a heavily WIP patch that only > John> touches plpgsql unreserved keywords, to test out the new > John> methodology in a limited area. After settling APIs and > John> name/directory bikeshedding, I'll move on to the other four > John> keyword types. > > Is there any particular reason not to go further and use a perfect hash > function for the lookup, rather than binary search?
The last time I looked into perfect hash functions, it wasn't easy to find a generator that competed with a decent normal hashtable (in particular gperf's are very unconvincing). The added tooling is a concern imo. OTOH, we're comparing not with a hashtable, but a binary search, where the latter will usually loose. Wonder if we shouldn't generate a serialized non-perfect hashtable instead. The lookup code for a read-only hashtable without concern for adversarial input is pretty trivial. Greetings, Andres Freund
