On Wed, Jun 24, 2020 at 10:27 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > More generally, though, why would we want to change this policy only > here? I believe we're reasonably consistent about letting the parser > do any required down-casing and then just checking keyword matches > with strcmp.
I've had the feeling in the past that our use of pg_strcasecmp() was a bit random. Looking through the output of 'git grep pg_strcasecmp', it seems like we don't typically don't use it on option names, but sometimes we use it on option values. For instance, DefineCollation() uses pg_strcasecmp() on the collproviderstr, and DefineType() uses it on storageEl; and also, not to be overlooked, defGetBoolean() uses it when matching true/false/on/off, which probably affects a lot of places. On the other hand, ExplainQuery() matches the format using plain old strcmp(), despite indirectly using pg_strcasecmp() for the Boolean parameters. So I guess I'm not really convinced that there is all that much consistency here. Mind you, I'm not sure whether or not anything really needs to be changed, or exactly what ought to be done. I'm just making the observation that it might not be as consistent as you may think. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
