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