Re: Review: UNNEST (and other functions) WITH ORDINALITY

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

In response to

Browse pgsql-hackers by date

  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