On Wed, Jun 24, 2020 at 12:55:22PM -0400, Tom Lane wrote:
> Yeah, I'm sure there are a few inconsistencies. We previously made a
> pass to get rid of pg_strcasecmp for anything that had been through
> the parser's downcasing (commit fb8697b31) but I wouldn't be surprised
> if that missed a few cases, or if new ones have snuck in. Anyway,
> "don't use pg_strcasecmp unnecessarily" was definitely the agreed-to
> policy as of Jan 2018.
0d8c9c1 has introduced some in parse_basebackup_options() for the
new manifest option, and fe30e7e for AlterType(), no?
> My vague recollection is that there are a few exceptions (defGetBoolean
> may well be one of them) where pg_strcasecmp still seemed necessary
> because the input might not have come through the parser in some usages.
Yep, there were a couple of exceptions. What was done at this time
was a case-by-case lookup to check what came only from the parser.
--
Michael