Re: Trailing comma support in SELECT statements

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Trailing comma support in SELECT statements
Date: 2014-10-17 22:11:50
Message-ID: 54419426.1020506@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/16/14, 11:48 PM, David Johnston wrote:
> We might as well allow a final trailing (or initial leading) comma on a
> values list at the same time:
<snip>

> do you know, so this feature is a proprietary and it is not based on ANSI/SQL? Any user, that use this feature and will to port to other database will hate it.
>
> ​I've got no complaint if "at the same time" means that neither behavior is ever implemented...

As I originally posted, if we're going to do this I think we should do it *EVERYWHERE* commas are used as delimiters, save COPY input and output. Or we should at least get close to doing it everywhere. I think the only way things could get more annoying is if we accepted extra commas in SELECT but not in CREATE TABLE (as one example).

To me completeness is more important than whether we do it or not; that said, I like the idea (as well as supporting leading extra commas).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-10-17 22:15:37 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Previous Message Marko Tiikkaja 2014-10-17 22:09:03 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch