From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: Review: UNNEST (and other functions) WITH ORDINALITY |
Date: | 2013-08-07 00:27:13 |
Message-ID: | 20130807002713.GA29934@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 06, 2013 at 11:10:11PM +0100, Greg Stark wrote:
> 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 am pretty sure we dismiss as "pilot error" foolishness at levels
much lower than this.
> I'm not 100% sure there aren't other cases where this can occur though.
If you don't find one considerably simpler, I'm inclined to say we
should let it lie, possibly with docs--even user-visible ones if you
think it's appropriate.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-08-07 00:54:52 | Re: refactor heap_deform_tuple guts |
Previous Message | Karl O. Pinc | 2013-08-06 23:50:23 | Re: Re: Doc Patch: Subquery section to say that subqueries can't modify data |