From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: Review: UNNEST (and other functions) WITH ORDINALITY |
Date: | 2013-08-06 22:10:11 |
Message-ID: | CAM-w4HN0vVvhjt+m-HqDPTXewPBJp-sLy0E9cOjCwCmeTjMwYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 5, 2013 at 1:31 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> This looks like really nice work.
It does. It's functionally equivalent to my attempt but with much better
comments and cleaner code.
But it doesn't seem to cover the case I was stumped on, namely "nulls
first" appearing in a place where two unreserved keywords can appear
consecutively. This doesn't happen for WITH_* before "with" is a reserved
keyword.
Looking into it a bit I see that the case I was most worried about is
actually a non-issue. We don't support column aliases without "AS" unless
the alias is completely unknown to the parser. That seems a bit of a
strange rule that must make the syntax with the missing AS pretty
unreliable if people are looking for code that will continue to work in
future versions. I never knew about this.
The only other case I could come up with in my regression tests is pretty
esoteric:
CREATE COLLATION nulls (locale='C');
ALTER OPERATOR CLASS text_ops USING btree RENAME TO first;
CREATE TABLE nulls_first(t text);
CREATE INDEX nulls_first_i ON nulls_first(t COLLATE nulls first);
I'm not 100% sure there aren't other cases where this can occur though.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2013-08-06 22:15:28 | Re: Doc Patch: Subquery section to say that subqueries can't modify data |
Previous Message | Karl O. Pinc | 2013-08-06 21:03:13 | Doc Patch: Subquery section to say that subqueries can't modify data |