Trailing comma support in SELECT statements
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 containing regression test (incorporated
into the serial_schedule).
My patch is relative to origin/REL9_4_STABLE branch as that is the one
I started from.
My plea is to have this change merged into the main stream so that it
becomes available in upcoming releases.
This modification does not require any interaction with user.
It does not create any backward compatibility issues.
Not does it have any performance impact.
regards
bogdan
Attachments:
0001-trailing_comma_support.patchtext/x-diff; charset=us-asciiDownload
>From 450c339b4284887782b30e154766a0ee90d6f7ee Mon Sep 17 00:00:00 2001
From: Bogdan Pilch <bogdan.pilch@opensynergy.com>
Date: Sat, 16 Aug 2014 19:42:29 +0200
Subject: [PATCH 1/3] BPI: Added support for ignoring the trailing comma in
select statement
---
src/backend/parser/gram.y | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 7b9895d..345c6cb 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -12470,6 +12470,7 @@ ctext_row: '(' ctext_expr_list ')' { $$ = $2; }
*****************************************************************************/
opt_target_list: target_list { $$ = $1; }
+ | target_list ',' { $$ = $1; }
| /* EMPTY */ { $$ = NIL; }
;
--
1.9.1
>From 9faf5eec4975eb99ad7c8901e30742ba92c0c4cb Mon Sep 17 00:00:00 2001
From: Bogdan Pilch <bogdan.pilch@opensynergy.com>
Date: Sun, 28 Sep 2014 13:12:24 +0200
Subject: [PATCH 3/3] Added regression test for trailing comma select feature.
---
.../regress/expected/select_trailing_comma.out | 53 ++++++++++++++++++++++
src/test/regress/serial_schedule | 1 +
src/test/regress/sql/select_trailing_comma.sql | 16 +++++++
3 files changed, 70 insertions(+)
create mode 100644 src/test/regress/expected/select_trailing_comma.out
create mode 100644 src/test/regress/sql/select_trailing_comma.sql
diff --git a/src/test/regress/expected/select_trailing_comma.out b/src/test/regress/expected/select_trailing_comma.out
new file mode 100644
index 0000000..f84938c
--- /dev/null
+++ b/src/test/regress/expected/select_trailing_comma.out
@@ -0,0 +1,53 @@
+--
+-- SELECT WITH TRAILING COMMA
+--
+CREATE TEMP TABLE primes (p1 int, p2 int, p3 int);
+INSERT INTO primes VALUES (13, 7927, 7);
+SELECT * FROM primes;
+ p1 | p2 | p3
+----+------+----
+ 13 | 7927 | 7
+(1 row)
+
+SELECT *, FROM primes;
+ p1 | p2 | p3
+----+------+----
+ 13 | 7927 | 7
+(1 row)
+
+SELECT p1 FROM primes;
+ p1
+----
+ 13
+(1 row)
+
+SELECT p1, FROM primes;
+ p1
+----
+ 13
+(1 row)
+
+SELECT p1, p2 FROM primes;
+ p1 | p2
+----+------
+ 13 | 7927
+(1 row)
+
+SELECT p1, p2, FROM primes;
+ p1 | p2
+----+------
+ 13 | 7927
+(1 row)
+
+SELECT p1, p2, p3 FROM primes;
+ p1 | p2 | p3
+----+------+----
+ 13 | 7927 | 7
+(1 row)
+
+SELECT p1, p2, p3, FROM primes;
+ p1 | p2 | p3
+----+------+----
+ 13 | 7927 | 7
+(1 row)
+
diff --git a/src/test/regress/serial_schedule b/src/test/regress/serial_schedule
index 16a1905..3571d14 100644
--- a/src/test/regress/serial_schedule
+++ b/src/test/regress/serial_schedule
@@ -79,6 +79,7 @@ test: select_distinct
test: select_distinct_on
test: select_implicit
test: select_having
+test: select_trailing_comma
test: subselect
test: union
test: case
diff --git a/src/test/regress/sql/select_trailing_comma.sql b/src/test/regress/sql/select_trailing_comma.sql
new file mode 100644
index 0000000..a2c922f
--- /dev/null
+++ b/src/test/regress/sql/select_trailing_comma.sql
@@ -0,0 +1,16 @@
+--
+-- SELECT WITH TRAILING COMMA
+--
+
+CREATE TEMP TABLE primes (p1 int, p2 int, p3 int);
+
+INSERT INTO primes VALUES (13, 7927, 7);
+
+SELECT * FROM primes;
+SELECT *, FROM primes;
+SELECT p1 FROM primes;
+SELECT p1, FROM primes;
+SELECT p1, p2 FROM primes;
+SELECT p1, p2, FROM primes;
+SELECT p1, p2, p3 FROM primes;
+SELECT p1, p2, p3, FROM primes;
--
1.9.1
Bogdan Pilch <bogdan@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 random misspellings of SELECT,
allowing mismatched parentheses in expressions, etc etc? It's important
in a computer language to be able to catch typos.
If we were going to be lax about trailing commas, the SELECT list
would hardly be the only candidate, or even the first candidate,
for being lax that way. But I don't want to go there.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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, c from t;
SELECT a, b, c, from t;Attached you can find a patch containing regression test (incorporated
into the serial_schedule).
My patch is relative to origin/REL9_4_STABLE branch as that is the one
I started from.My plea is to have this change merged into the main stream so that it
becomes available in upcoming releases.This modification does not require any interaction with user.
It does not create any backward compatibility issues.
Interesting --- I know some languages allow trailing delimiters, like
Perl and Javascript. Could this mask query errors? Does any other
database accept this? Seems this would need to be done in many other
places, like UPDATE, but let's first decide if we want this.
FYI, it is usually better to discuss a feature before showing a patch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 both (with the same result):
SELECT a, b, c from t;
SELECT a, b, c, from t;Attached you can find a patch containing regression test (incorporated
into the serial_schedule).
My patch is relative to origin/REL9_4_STABLE branch as that is the one
I started from.My plea is to have this change merged into the main stream so that it
becomes available in upcoming releases.This modification does not require any interaction with user.
It does not create any backward compatibility issues.Interesting --- I know some languages allow trailing delimiters, like
Perl and Javascript. Could this mask query errors? Does any other
database accept this? Seems this would need to be done in many other
places, like UPDATE, but let's first decide if we want this.FYI, it is usually better to discuss a feature before showing a patch.
Javascript might accept it, but it's not valid JSON.
The case for doing it is that then you can easily comment out any entry
at all in a select list:
select
foo as f1,
bar as f2,
-- baz as f3,
from blurfl
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 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 containing regression test (incorporated
into the serial_schedule).
My patch is relative to origin/REL9_4_STABLE branch as that is the one
I started from.My plea is to have this change merged into the main stream so that it
becomes available in upcoming releases.This modification does not require any interaction with user.
It does not create any backward compatibility issues.Interesting --- I know some languages allow trailing delimiters, like
Perl and Javascript. Could this mask query errors? Does any other
database accept this? Seems this would need to be done in many other
places, like UPDATE, but let's first decide if we want this.FYI, it is usually better to discuss a feature before showing a patch.
Javascript might accept it, but it's not valid JSON.
The case for doing it is that then you can easily comment out any entry
at all in a select list:select
foo as f1,
bar as f2,
-- baz as f3,
from blurfl
Should we also allow:
SELECT
, col1
, col2
, col3
FROM ...
?
The other reason for this would be to build dynamic SQL more easily via a
loop.
Barring arguments showing danger allowing I don't see a reason to reject
this; let people decide whether they want to utilize it on stylistic or
compatibility grounds.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Trailing-comma-support-in-SELECT-statements-tp5821613p5821694.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-09-28 13:42 GMT+02:00 Bogdan Pilch <bogdan@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, but then
developers will hate us, when they will try to port to other servers.
-1 from me
Regards
Pavel
Show quoted text
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 containing regression test (incorporated
into the serial_schedule).
My patch is relative to origin/REL9_4_STABLE branch as that is the one
I started from.My plea is to have this change merged into the main stream so that it
becomes available in upcoming releases.This modification does not require any interaction with user.
It does not create any backward compatibility issues.
Not does it have any performance impact.regards
bogdan--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 around" this problem is:
SELECT
blah
, foo
, bar
, baz
In my experience, it's quite uncommon to mess with the first item in the list, which mostly eliminates the issue. A missing leading comma is also MUCH easier to spot than a missing trailing comma.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
FWIW, the way I normally "work around" this problem is:
SELECT
blah
, foo
, bar
, bazIn my experience, it's quite uncommon to mess with the first item in the
list, which mostly eliminates the issue. A missing leading comma is also
MUCH easier to spot than a missing trailing comma.--
Sent via pgsql-hackers mailing list (
pgsql-hackers@
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
FWIW, the way I normally "work around" this problem is:
SELECT
blah
, foo
, bar
, bazIn my experience, it's quite uncommon to mess with the first item in the
list, which mostly eliminates the issue. A missing leading comma is also
MUCH easier to spot than a missing trailing comma.
We might as well allow a final trailing (or initial leading) comma on a
values list at the same time:
VALUES
(...),
(...),
(...),
;
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Trailing-comma-support-in-SELECT-statements-tp5821613p5823365.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-10-17 6:34 GMT+02:00 David G Johnston <david.g.johnston@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
than trailing commas.
If we are going to do this, we need to do it EVERYWHERE.
FWIW, the way I normally "work around" this problem is:
SELECT
blah
, foo
, bar
, bazIn my experience, it's quite uncommon to mess with the first item in the
list, which mostly eliminates the issue. A missing leading comma is also
MUCH easier to spot than a missing trailing comma.
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.
Regards
Pavel
Show quoted text
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackersJim 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.
FWIW, the way I normally "work around" this problem is:
SELECT
blah
, foo
, bar
, bazIn my experience, it's quite uncommon to mess with the first item in the
list, which mostly eliminates the issue. A missing leading comma is also
MUCH easier to spot than a missing trailing comma.We might as well allow a final trailing (or initial leading) comma on a
values list at the same time:VALUES
(...),
(...),
(...),
;David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Trailing-comma-support-in-SELECT-statements-tp5821613p5823365.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 will hate it.Regards
Pavel
I've got no complaint if "at the same time" means that neither behavior is
ever implemented...
David J.
Pavel Stehule <pavel.stehule@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 definition, which was handy. I checked on
SQL Fiddle and found that MS SQL Server and MySQL both allow that,
too; although Oracle does not. I'm not taking a position on
whether we should allow this in PostgreSQL, but not having it is
likely to annoy some users moving *to* PostgreSQL, while having it
is likely to annoy some users moving *away* from PostgreSQL.
None of the products I tried allowed a leading comma.
I didn't test, and have no knowledge regarding, how other products
treat extra commas elsewhere.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 to port to other database will hate it.
I've got no complaint if "at the same time" means that neither behavior is ever implemented...
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).
--
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
Jim Nasby <Jim.Nasby@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 17, 2014, at 3:18 PM, Tom Lane <tgl@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
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
0� *�H��
��0�1 0 + 0� *�H��
�� i0�-0�� �0
*�H��
0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0
140905115440Z
150906110220Z0F1 0 U david@justatheory.com1$0" *�H��
david@justatheory.com0�"0
*�H��
� 0�
� �2 ? }�^�#4��F&eR(s��z��I0��%�Ado%j��-"Zp��4��f*�?��-�� �IA ��dyD��i ?�w�J��C��R�2u��u
��>��A���
WX~� ������S=j����z����j7����F��i���K���"�{�^�6s���w��E�o�W��pn�QC��5 ���g����]O��o�� o�@��P2v������`!E�y<t�D�ei��������>�(u��z_�������0y�v���/ ���0��0 U 0 0 U �0 U %0++0 U [k�����3�{���<>��0 U #0�Sr������\|~�5N���Q�0 U 0�david@justatheory.com0�LU �C0�?0�; +��70�*0.+"http://www.startssl.com/policy.pdf0��+0��0' StartCom Certification Authority0��This certificate was issued according to the Class 1 Validation requirements of the StartCom CA policy, reliance only for the intended purpose in compliance of the relying party obligations.06U /0-0+�)�'�%http://crl.startssl.com/crtu1-crl.crl0��+��009+0�-http://ocsp.startssl.com/sub/class1/client/ca0B+0�6http://aia.startssl.com/certs/sub.class1.client.ca.crt0#U 0�http://www.startssl.com/0
*�H��
� 2l�T� �b�� *Z�J �R�*L��)� ��T�u
I���crbl��K��
�.��k��k*��ZLt�A����SJU��n���@�0���[#Y��g��X�q�}��������Y�@�Wp���wK��pXj�B~C�����G������J�KI*[(�to�� ��:�9�0�NW$ld���!�o����{�B���[P�� ',?��T�����Q���V�� �����C[�c��K�j��b�g�p��f|�V���0�40� � 0
*�H��
0}1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0
071024210155Z
171024210155Z0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0�"0
*�H��
� 0�
� � ���-��)�.����2����A�UG��o���#G�
��B|N�D�����Rp�M-��B��=o��� -�we�5��J�Qpa>O��.�#������.���_�<���V��
[~�*��*�p�z��~�3�W�G� .�������Ml�r[�<C�e�6���f����q������O���"��u��xf�WN�#�u����i���c�gk��v$����Lb�%�������y��`�����_�{`���xK'G�N��� ���0��0U �0�0U �0 U Sr������\|~�5N���Q�0 U #0�N ��@[�i�0�4hC�A��0f+Z0X0'+0�http://ocsp.startssl.com/ca0-+0�!http://www.startssl.com/sfsca.crt0[U T0R0'�%�#�!http://www.startssl.com/sfsca.crl0'�%�#�!http://crl.startssl.com/sfsca.crl0��U y0w0u +��70f0.+"http://www.startssl.com/policy.pdf04+(http://www.startssl.com/intermediate.pdf0
*�H��
�
�}x�,\�c�^� �#wM�q�}��>UK/��^y��X��y �����f�rMI���B6�1ymQ���������Z���0���& ��;�@��#13q����& ����������o� 6�r��_��;�GO>*I�( 7�4����XS1r3��)!����y��6Ko����t��#
_�w�S�r����
�;�B
A�Dp�(f��s����� �����6%�����.W0J3�:b�C�<�8t X����1�<��C��n�=�����t==�wS���T������~���\�wkB�f�|1���5���zU��P)��(���I��j��VB��!����OfI=b��b�\4�-*em��/��SJm�7���N�����[�]'��@���� D9�Kr>���R��7/����|�o���^I@���'��Pa $ z��9�a'L�)��(�
�I��}v��c�H]����D����*��W�}
m�>Q����|�C.�(,�l��Q�1�o0�k0��0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA �0 + ���0 *�H��
1 *�H��
0 *�H��
1
141018041947Z0# *�H��
1]7��h�G�|����m�~�6�0�� +�71��0��0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA �0�� *�H��
1�����0��1 0 UIL10U
StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA �0
*�H��
� ��4o������l����Rl��5=�g�T�!\H�Cg�
�(:��g;��h�������~T;=��o�M�1.�O@,YM� ?��oV��s�d�N�Cs ��j���+�i-�����/�������]pK�=E0 ��8�[� D������� �����2�T�����$P ��G�3;�s���{ fGY�Hw�{3]�����8��\_^p)������F@@�����`�\ ������8�����+Pl�>���_lb�4��km����fF� On 10/17/14, 11:19 PM, David E. Wheeler wrote:
On Oct 17, 2014, at 3:18 PM, Tom Lane <tgl@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.
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 do think such a change should be made in stages, and maybe not every last one makes it into 9.5, but the intention should certainly be that we support extra delimiters *everywhere*.
--
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
On Oct 18, 2014, at 7:06 PM, Jim Nasby <Jim.Nasby@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.
D
Attachments:
On 10/20/2014 11:59 AM, David E. Wheeler wrote:
On Oct 18, 2014, at 7:06 PM, Jim Nasby <Jim.Nasby@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).
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.Nasby@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
Jim Nasby <Jim.Nasby@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 - 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane <tgl@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 SQL statements for various purposes, e.g. for
dependency analysis.
This is a misfeature for the benefit of edit-lazy users only.
-- Alex
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-10-28 13:20 GMT+01:00 Alvaro Herrera <alvherre@2ndquadrant.com>:
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
+1
Pavel
Show quoted text
--
Álvaro Herrera http://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
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUT+MWAAoJEDfy90M199hllO8QAICsG86NK9hQE4QPLppIMkbv
E5qGAv0Hml/g+dKtsDpxo1f2L5dguQnAQD7ERZeEMWv0X28PixN+PDxfUVUjFKm2
5uI+OiJ60xM4oN+/eNgt4gaJWgk8osVmS9lx4jcGRTY+z9loxLQVUvWJ04nEdbV4
CJjcC6QZB0bpIDSkWYPZIB/YYrBLZ+/gI2GMWSIye8QutshHXd0Bca6gqWcgrBcK
sRVTVYd9hTNjnDLYPxSipuMJWHsyObMsSOnA0G9NuT+itj817uhOJhLOSq/Ctu02
C43CT4tM8Y0PX+EHhnkg2m0FMLeVYrSU8dCMI6MgjbSaghqjPRYHYjHoXyE9zqEk
M2Vw3qsqax0hx1AAJr//PIrCTf2Kc7T5K2soZkUXaIwrilrk7GTW1wtl+OCizn5D
Che5XCdwivh3m0Q6Wx/jtvdMqm1aJVA137kvHFLgR4SxkH2af/jhsP26ol5ieiAx
lno00w3JSjjeVl+EFzDTVBDsFD0FRffdlUxB1V+gUUQ+XvOdpfZEbyppQfP01+Bd
2WHnc2tYr0QJKWwnInFMeN+OHP7cOvE5C1I48DIZUSvI76astP3QWPtFXa30xFiA
CZUjzAKOqDQFvTpnHNMHoKRGCv28WZ525b5TPICWSO7EBaG2Uz/kMBvGXq4h6fOW
g9Rrm4UuMcMxoHhWoz2T
=JZC8
-----END PGP SIGNATURE-----
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 24, 2014, at 6:36 AM, Alex Goncharov <alex.goncharov.usa@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 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.
Best,
David
Attachments:
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 is pretty stupid. I can understand why we wouldn't want to break backwards compatibility, but I think it does us and our users a disservice to dismiss the issue.
(BTW, I use a "comma first" formatting standard, so this doesn't actually effect me much, but I still find the original complaint very valid.)
--
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
Jim Nasby <Jim.Nasby@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. I can understand why we wouldn't want to break backwards compatibility, but I think it does us and our users a disservice to dismiss the issue.
I don't think anyone is just dismissing the issue. But it is certainly a
judgment call as to whether the pros outweigh the cons, and I'm not seeing
a clear majority of us thinking they do.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 24, 2014 at 6:36 AM, Alex Goncharov <
alex.goncharov.usa@gmail.com> wrote:
On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane <tgl@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 SQL statements for various purposes, e.g. for
dependency analysis.
If you hit the tool before you hit PostgreSQL then obviously you need to
conform to whatever it accepts.
For SQL directly generated from system catalogs we should not add extra
commas. Function text is obviously one area where we keep queries as-is so
how does this play with existing pl/pgsql static analysis routines?
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.
I do like the idea of being able to write "column," instead of ", column"
with fewer "ooops" moments and marginal diff differences.
David J.
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jim Nasby <Jim.Nasby@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. I can understand why we wouldn't want to break
backwards compatibility, but I think it does us and our users a
disservice to dismiss the issue.I don't think anyone is just dismissing the issue. But it is
certainly a judgment call as to whether the pros outweigh the
cons, and I'm not seeing a clear majority of us thinking they do.
+1
My personal experience with products which allowed this (at least
in some circumstances) was that it occasionally saved me from an
"oops, ROLLBACK, retry" cycle. I feel there is some value to that.
It also seems probable that some people on such products maintain
their DDL scripts in this format to minimize such cycles in their
current environments, and for them the lack of such behavior in
PostgreSQL will cause some extra bumps on the road to conversion.
Smoothing the road for conversion to PostgreSQL also seems to have
some value.
I feel that these are both fairly small benefits, so in the absence
of any information on the costs of developing and maintaining this,
I don't have any opinion on whether it is worth it. I don't like
the scope of the initial proposal because that is not the place
where I noticed the feature in other products, and thus doubt that
it is the most important place to make the change, and think that
if we do it we had better have more consistency with it. If
someone offered a more comprehensive patch, I could look at it and
develop an opinion on whether the cost/benefit ratio looked like it
was worth it.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 28, 2014 at 7:59 PM, David Johnston
<david.g.johnston@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 experience with this kind of thing has not been positive. You
write all your code in strict mode and have it turned on server-wide,
and then you want to install an extension which doesn't use strict
mode and you have to turn it off, but then you lose your own checks.
Uggh.
I think the discussion here is an example of taking a questionable
idea to its illogical conclusion. I don't believe that a decision to
allow a trailing comma in a SELECT list means that we also have to
allow trailing commas in every single kind of comma-separated list we
have anywhere in PostgreSQL, right down to some obscure type's input
functions. That's taking a simple idea that might possibly be worth
considering and expanding it into a giant project that nobody's ever
going to do, and certainly not correctly.
My personal vote is for not changing anything here at all. But I
don't think it's got to be all-or-nothing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers