Tom Lane t...@sss.pgh.pa.us wrote:
Jim Nasby jim.na...@bluetreble.com writes:
On 10/28/14, 4:25 PM, David E. Wheeler wrote:
This one, however, is more a judgment of people and their
practices rather than the feature itself. Color me unimpressed.
+1.
Having users sweat of comma placement in
On Tue, Oct 28, 2014 at 7:59 PM, David Johnston
david.g.johns...@gmail.com wrote:
I'd be much more inclined to favor this if the user is provided a capability
to have warnings emitted whenever extraneous commas are present - either via
some form of strict mode or linting configuration.
My
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
2014-10-28 13:20 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
+1
Pavel
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2014 05:20 AM, Alvaro Herrera wrote:
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
+1
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
On Oct 24, 2014, at 6:36 AM, Alex Goncharov alex.goncharov@gmail.com
wrote:
Another dimension of the trouble is breaking the operation of the
tools that parse SQL statements for various purposes, e.g. for
dependency analysis.
That’s a valid point.
This is a misfeature for the benefit
On 10/28/14, 4:25 PM, David E. Wheeler wrote:
This is a misfeature for the benefit of edit-lazy users only.
This one, however, is more a judgment of people and their practices rather than
the feature itself. Color me unimpressed.
+1.
Having users sweat of comma placement in this day and age
Jim Nasby jim.na...@bluetreble.com writes:
On 10/28/14, 4:25 PM, David E. Wheeler wrote:
This one, however, is more a judgment of people and their practices rather
than the feature itself. Color me unimpressed.
+1.
Having users sweat of comma placement in this day and age is pretty stupid.
On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(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.
Another dimension of the trouble is breaking the operation of the
tools that parse
Jim Nasby jim.na...@bluetreble.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
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
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 ;
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
On 10/17/14, 11:19 PM, David E. Wheeler wrote:
On Oct 17, 2014, at 3:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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.
PL/pgSQL, too, I
Pavel Stehule pavel.steh...@gmail.com wrote:
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 remember that Sybase ASE allowed a trailing comma within the
parentheses of a table
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
Jim Nasby jim.na...@bluetreble.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
On Oct 17, 2014, at 3:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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.
PL/pgSQL, too, I presume.
D
smime.p7s
Description: S/MIME
Jim Nasby-5 wrote
On 10/3/14, 4:02 PM, David G Johnston wrote:
Should we also allow:
SELECT
, col1
, col2
, col3
FROM ...
?
I would say yes, if we're going to do this. I don't see it being any worse
than trailing commas.
If we are going to do this, we need to do it EVERYWHERE.
2014-10-17 6:34 GMT+02:00 David G Johnston david.g.johns...@gmail.com:
Jim Nasby-5 wrote
On 10/3/14, 4:02 PM, David G Johnston wrote:
Should we also allow:
SELECT
, col1
, col2
, col3
FROM ...
?
I would say yes, if we're going to do this. I don't see it being any
worse
We might as well allow a final trailing (or initial leading) comma on a
values list at the same time:
VALUES
(...),
(...),
(...),
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
On 10/3/14, 4:02 PM, David G Johnston wrote:
Should we also allow:
SELECT
, col1
, col2
, col3
FROM ...
?
I would say yes, if we're going to do this. I don't see it being any worse than
trailing commas.
If we are going to do this, we need to do it EVERYWHERE.
FWIW, the way I normally work
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that accepts trailing comma at the end of list in
SELECT statement.
The idea is to be able to say both (with the same result):
SELECT a, b, c from t;
SELECT a, b, c, from t;
Attached you can find a patch
Bogdan Pilch bog...@matfyz.cz writes:
I have created a small patch to postgres source (in particular the
psql part of it) that accepts trailing comma at the end of list in
SELECT statement.
This doesn't seem to me to be a remarkably good idea. What's the
difference between this and accepting
On Sun, Sep 28, 2014 at 01:42:46PM +0200, Bogdan Pilch wrote:
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that accepts trailing comma at the end of list in
SELECT statement.
The idea is to be able to say both (with the same result):
SELECT a, b,
On 10/03/2014 12:20 PM, Bruce Momjian wrote:
On Sun, Sep 28, 2014 at 01:42:46PM +0200, Bogdan Pilch wrote:
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that accepts trailing comma at the end of list in
SELECT statement.
The idea is to be able to say
Andrew Dunstan wrote
On 10/03/2014 12:20 PM, Bruce Momjian wrote:
On Sun, Sep 28, 2014 at 01:42:46PM +0200, Bogdan Pilch wrote:
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that accepts trailing comma at the end of list in
SELECT statement.
The
2014-09-28 13:42 GMT+02:00 Bogdan Pilch bog...@matfyz.cz:
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that accepts trailing comma at the end of list in
SELECT statement.
It is ANSI/SQL ?
Why we should to enable? We can be tolerant to this bug,
28 matches
Mail list logo
