Re: Refactoring identifier checks to consistently use strcmp

> On 16 Aug 2017, at 17:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> This no longer works:
>
>> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict (
>> TEMPLATE = pg_catalog.simple,
>> "STOPWORds" = english
>> );
>> ERROR: unrecognized simple dictionary parameter: "STOPWORds"
>
>> In hindsight, perhaps we should always have been more strict about that
>> to begin wtih, but let's not break backwards-compatibility without a
>> better reason. I didn't thoroughly check all of the cases here, to see
>> if there are more like this.
>
> You have a point, but I'm not sure that this is such a bad compatibility
> break as to be a reason not to change things to be more consistent.

I agree with this, but I admittedly have no idea how common the above case
would be in the wild.

>> It'd be nice to have some kind of a rule on when pg_strcasecmp should be
>> used and when strcmp() is enough. Currently, by looking at the code, I
>> can't tell.
>
> My thought is that if we are looking at words that have been through the
> parser, then it should *always* be plain strcmp; we should expect that
> the parser already did the appropriate case-folding.

+1

> pg_strcasecmp would be appropriate, perhaps, if we're dealing with stuff
> that somehow came in without going through the parser.

In that case it would be up to the consumer of the data to handle required
case-folding for the expected input, so pg_strcasecmp or strcmp depending on
situation.

cheers ./daniel