Re: Trailing comma support in SELECT statements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, 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-21 14:16:38
Message-ID: 14881.1413900998@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:
> On 10/20/14, 11:16 AM, Andrew Dunstan wrote:
>> The JSON spec is quite clear on this. Leading and trailing commas are not allowed. I would fight tooth and nail not to allow it for json (and by implication jsonb, since they use literally the same parser - in fact we do that precisely so their input grammars can't diverge).

> +1. Data types that implement specs should follow the spec.

> I was more concerned about things like polygon, but the real point (ha!) is that we need to think about the data types too. (I will say I don't think things that mandate an exact number of elements (like point, box, etc) should support extra delimiters).

I'm pretty strongly against this, as it would create cross-version hazards
for data. Having queries that depend on newer-version SQL features is
something that people are used to coping with ... but data that loads into
some versions and not others seems like a hassle we do not need to invent.

(Of course, I'm not for the feature w.r.t. SQL either. But breaking data
compatibility is just adding an entire new dimension of trouble.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-10-21 14:26:05 Re: Wait free LW_SHARED acquisition - v0.2
Previous Message Michael Paquier 2014-10-21 13:47:35 Re: Inconsistencies in documentation of row-level locking