Re: SQL access to database attributes

Hello

I returned to review this patch after sleeping - and I have to say, these
patches doesn't break a compatibility.

This feature has two patches:
createdb_alterdb_grammar_refactoring.v1-1.patch and
database_attributes.v2-1.patch. First patch do some cleaning in gram rules
a CREATE DATABASE and ALTER DATABASE statements (and introduce a
CONNECTION_LIMIT property). Second patch introduces ALLOW_CONNECTIONS and
IS_TEMPLATE database properties. A motivation for these patches is cleaning
alterdb/createdb grammars and drop necessity to directly modify pg_database
table.

1. these patch does what was proposed, there was not any objection in
related discussion
2. I can apply these patches cleanly, a compilation was without new
warnings and without errors
3. all tests was passed
4. there is a necessary documentation (for new features)
5. a new syntax is actively used in initdb and pg_upgrade. I am not sure,
if some special test is necessary and if we are able to test it.

Refactoring of alterdb/createdb grammars has sense and we would it.

I found only one problem - first patch introduce a new property
CONNECTION_LIMIT and replace previously used "CONNECTION LIMIT" in
documentation. But "CONNECTION LIMIT" is still supported, but it is not
documented. So for some readers it can look like breaking compatibility,
but it is false. This should be documented better.

Regards

Pavel

2014-06-21 23:14 GMT+02:00 Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>:

> On 06/21/2014 10:11 PM, Pavel Stehule wrote:
> > Hello
> >
> > I am looking createdb_alterdb_grammar_refactoring.v1.patch
> >
> > http://www.postgresql.org/message-id/53868E57.3030908@dalibo.com
>
> Thank you for looking at this.
>
> > 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.
>
> > Surely this patch cannot be backported what is proposed there.
>
> There are reasons I can think of not to backport this first patch, but
> breaking compatibility isn't one of them.
> --
> Vik
>