Re: [HACKERS] Refactoring identifier checks to consistently use strcmp - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Refactoring identifier checks to consistently use strcmp
Date
Msg-id 8888.1515285483@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Refactoring identifier checks to consistently usestrcmp  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] Refactoring identifier checks to consistently use strcmp
Re: [HACKERS] Refactoring identifier checks to consistently use strcmp
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Thinking through it, for my own 2c on this, I tend to agree with Tom
> that, really, we should be using strcmp() for anything coming out of the
> parser and that the backward-compatibility break from that is
> acceptable.  I also understand Robert's concern that there may be other
> bugs hiding and I wonder if there might be a way to check for them,
> though no great ideas spring to mind offhand.  Would be great to hear
> your thoughts, Daniel, so leaving this in Waiting on Author for now.

FWIW, I don't especially agree with Robert's position, because I think
he is ignoring the argument that it's a bug that some things are
case-sensitive and other seemingly similar things are not.

It's definitely concerning that the submitted patch introduced a new bug,
but we have seldom taken the position that bugs in an initial submission
are sufficient grounds for rejecting the entire concept.

ISTM that if this patch gets rid of a large fraction of the uses of
pg_strcasecmp in the backend, which is what I expect it should, then
it might not be out of reach to go through all the surviving ones to
make sure they are not processing strings that originate in the parser.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Refactoring identifier checks to consistently usestrcmp
Next
From: Chapman Flack
Date:
Subject: Re: proposal: alternative psql commands quit and exit