Re: SQL access to database attributes

From: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
To: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <jim(at)nasby(dot)net>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>
Subject: Re: SQL access to database attributes
Date: 2014-05-29 01:33:11
Message-ID: 53868E57.3030908@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/26/2014 08:19 PM, Vik Fearing wrote:
> On 05/26/2014 07:10 AM, Stephen Frost wrote:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> I don't really object to doing an unlocked check for another such
>>> database, but I'm not convinced that additional locking to try to
>>> prevent a race is worth its keep.
>> +1 on the nannyism, and +1 to ignoring the race.
> Okay, I'll submit a new patch with racy nannyism and some grammar
> changes that Tom and I have been discussing in private.

Attached are two patches.

The first is a refactoring of the createdb/alterdb grammars mostly by
Tom which makes all of the options non-keywords that don't otherwise
need to be. Not only does this remove the two unreserved keywords I had
added (ALLOW and CONNECTIONS) but also removes two existing ones
(LC_COLLATE and LC_TYPE), reducing gram.o by about half a percent by
Tom's calculations. That's much better than increasing it like my
original patch did.

The problem is we foolishly adopted a two-word option name (CONNECTION
LIMIT) which complicates the grammar. My aping of that for IS TEMPLATE
and ALLOW CONNECTIONS only aggravated the situation. And so I changed
all the documentation (and pg_dumpall etc) to use CONNECTION_LIMIT
instead. We might hopefully one day deprecate the with-space version so
the sooner the documentation recommends the without-space version, the
better. The old syntax is of course still valid.

I also changed the documentation to say connection_limit instead of
connlimit. Documentation is for humans, something like "connlimit" (and
later as we'll see allowconn) is for programmers. It also indirectly
reminds us that we should not add another multi-word option like I
initially did.

Now that anything goes grammar-wise, the elog for unknown option is now
ereport.

I am hoping this gets backpatched.

-------

The second patch adds my original functionality, except this time the
syntax is IS_TEMPLATE and ALLOW_CONNECTIONS (both one word, neither
being keywords). It also changes all the catalog updates we used to do
because we didn't have this patch.

As for the nannyism, the point was to find another database having
datallowconn=true but since we have to be connected to a database to
issue this command, the simplest is just to disallow the current
database (credit Andres on IRC) so that's what I've done as explained
with this in-code comment:

/*
* In order to avoid getting locked out and having to go through
standalone
* mode, we refuse to disallow connections on the database we're
currently
* connected to. Lockout can still happen with concurrent
sessions but the
* likeliness of that is not high enough to worry about.
*/

I also changed the C variable connlimit to dbconnlimit in
AlterDatabase() to be consistent with its analog in createdb().

-------

The third and non-existent patch is about regression tests. Tom put in
gram.y that we should have some now that the grammar doesn't regulate
it, and I wanted some anyway in my original patch; but I don't know what
they should look like or where they should go so I'm asking for help on
that.

--
Vik

Attachment Content-Type Size
createdb_alterdb_grammar_refactoring.v1.patch text/x-diff 19.2 KB
database_attributes.v2.patch text/x-diff 15.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-05-29 01:59:23 Ancient bug in formatting.c/to_char()
Previous Message Tom Lane 2014-05-29 01:23:09 Avoiding re-creation of uuid_t state with OSSP UUID