On 10/20/14, 11:16 AM, Andrew Dunstan wrote:
On 10/20/2014 11:59 AM, David E. Wheeler wrote:
On Oct 18, 2014, at 7:06 PM, Jim Nasby <jim.na...@bluetreble.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).
+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).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
