On Tue, Oct 28, 2014 at 7:59 PM, David Johnston
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
Tom Lane wrote:
> Jim Nasby 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
>> pr
On Fri, Oct 24, 2014 at 6:36 AM, Alex Goncharov <
alex.goncharov@gmail.com> wrote:
> On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane 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.
>>
>
> Anot
Jim Nasby 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 understa
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
On Oct 24, 2014, at 6:36 AM, Alex Goncharov
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.
-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
2014-10-28 13:20 GMT+01:00 Alvaro Herrera :
> 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
>
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 change
On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane 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
Jim Nasby 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
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 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
g
On 10/20/2014 11:59 AM, David E. Wheeler wrote:
On Oct 18, 2014, at 7:06 PM, Jim Nasby 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 po
On Oct 18, 2014, at 7:06 PM, Jim Nasby 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
On 10/17/14, 11:19 PM, David E. Wheeler wrote:
On Oct 17, 2014, at 3:18 PM, Tom Lane 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 on
On Oct 17, 2014, at 3:18 PM, Tom Lane 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 cryptographic signature
Jim Nasby 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 accept
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:
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 po
Pavel Stehule 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 h
>
>
>
>
>> 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
2014-10-17 6:34 GMT+02:00 David G Johnston :
> 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
> wor
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 d
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
2014-09-28 13:42 GMT+02:00 Bogdan Pilch :
> 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
devel
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 state
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 b
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
Bogdan Pilch 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 misspel
28 matches
Mail list logo
