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 13603.1517009811@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Refactoring identifier checks to consistently use strcmp  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: [HACKERS] Refactoring identifier checks to consistently use strcmp
Re: [HACKERS] Refactoring identifier checks to consistently use strcmp
List pgsql-hackers
I've pushed this mostly as-is.  I fixed the missed places in reloptions
code as we discussed.  I also took out the parser changes related to
allowing unquoted PARALLEL in old-style CREATE AGGREGATE, because that
is not a goal I consider worthy of adding extra grammar complexity.
We don't document that PARALLEL works there, and there has never been
any expectation that deprecated legacy syntax would grow new options
as needed to have feature parity with the modern syntax.  I don't feel
a need to go out of our way to prevent new options from working in the
old syntax, if they happen to, but I definitely don't want to expend
code on making them do so.

Accordingly, that regression test that expected PARALLEL to work in
the old-style syntax was just ill-considered, and I changed it to use
the new-style syntax instead.

I also trimmed the new regression test cases a bit, as most of them seemed
pretty duplicative.  How many times do we need to verify that the lexer
doesn't downcase quoted identifiers?  I'm not really sure that checking
this behavior from SQL is useful at all, actually.  The interesting
question is whether there are code paths that can reach these string
comparisons with strings that *didn't* get processed as identifiers by the
lexer, and these tests do basically nothing to prove that there aren't.
Still, I think we can push this and wait to see if there are complaints.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Oliver Ford
Date:
Subject: Re: Add RANGE with values and exclusions clauses to the Window Functions
Next
From: Andres Freund
Date:
Subject: Re: Setting BLCKSZ 4kB