Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Refactoring identifier checks to consistently use strcmp
Date: 2018-02-01 19:03:23
Message-ID: CA+TgmoY5PVnpqHYAHXKtLc39bbjQ9Hmfo8JbUhxH-bWN1ATjRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 26, 2018 at 6:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I think it's a shame that the commit message didn't document (for the
release notes) exactly which cases just got changed incompatibly. I
admit that not many people are likely to get bitten by this, but I
still think it's better if we're precise about what might cause a
particular user to be in that set.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-02-01 19:39:23 Re: [HACKERS] MERGE SQL Statement for PG11
Previous Message Robert Haas 2018-02-01 18:55:57 Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()