> On 16 Aug 2017, at 17:51, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Heikki Linnakangas <hlinn...@iki.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
