| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-20 16:16:52 |
| Message-ID: | 54453574.4030106@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/20/2014 11:59 AM, David E. Wheeler wrote:
> On Oct 18, 2014, at 7:06 PM, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> wrote:
>
>> Yes.
>>
>> The only case I can think of where we wouldn't want this is COPY.
>>
>> BTW, this should also apply to delimiters other than commas; for example, some geometry types use ; as a delimiter between points.
> I don’t think it should apply to the internals of types, necessarily. JSON, for example, always dies on an trailing comma, so should probably stay that way. Well, maybe allow it on JSONB input, but not JSON. Though we perhaps don’t want their behaviors to diverge.
>
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).
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-10-20 18:19:43 | Re: Superuser connect during smart shutdown |
| Previous Message | David G Johnston | 2014-10-20 16:02:32 | Re: Would you help to review our modifications |