| 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: | Whole Thread | Raw Message | 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
| 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() |