Re: SQL access to database attributes - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: SQL access to database attributes
Date
Msg-id CAFj8pRBR0+FpCmvtNpQQACwXwEOgP+jaL_y8wzVN5fN1Jv25Wg@mail.gmail.com
Whole thread Raw
In response to Re: SQL access to database attributes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers



2014-06-29 21:09 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Vik Fearing <vik.fearing@dalibo.com> writes:
> On 06/21/2014 10:11 PM, Pavel Stehule wrote:
>> Is any reason or is acceptable incompatible change CONNECTION_LIMIT
>> instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough
>> for breaking compatibility?

> How is compatibility broken?  The grammar still accepts the old way, I
> just changed the documentation to promote the new way.

While I agree that this patch wouldn't break backwards compatibility,
I don't really see what the argument is for changing the recommended
spelling of the command.

The difficulty with doing what you've done here is that it creates
unnecessary cross-version incompatibilities; for example a 9.5 psql
being used against a 9.4 server would tab-complete the wrong spelling
of the option.  Back-patching would change the set of versions for
which the problem exists, but it wouldn't remove the problem altogether.
And in fact it'd add new problems, e.g. pg_dumpall output from a 9.3.5
pg_dumpall failing to load into a 9.3.4 server.  This is not the kind of
change we customarily back-patch anyway.

So personally I'd have just made connection_limit be an undocumented
internal equivalent for CONNECTION LIMIT, and kept the latter as the
preferred spelling, with no client-side changes.

+1

There is no important reason do hard changes in this moment

Pavel

 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Next
From: Michael Paquier
Date:
Subject: Re: IMPORT FOREIGN SCHEMA statement