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 <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 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.
