| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
| Cc: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Trailing comma support in SELECT statements |
| Date: | 2014-10-17 22:18:47 |
| Message-ID: | 11052.1413584327@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> 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).
Yeah, exactly. Personally I'm *not* for this, but if we do it we should
do it consistently: every comma-separated list in the SQL syntax should
work the same.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2014-10-17 22:34:31 | Re: Superuser connect during smart shutdown |
| Previous Message | Tom Lane | 2014-10-17 22:15:37 | Re: get_actual_variable_range vs idx_scan/idx_tup_fetch |