SQL access to database attributes

From: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
To: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: SQL access to database attributes
Date: 2014-05-24 03:53:56
Message-ID: 538017D4.6060901@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

We try to tell our clients not to update the catalogs directly, but
there are at least two instances where it's not possible to do otherwise
(pg_database.datistemplate and .datallowconn). This patch aims to
remedy that.

For example, it is now possible to say
ALTER DATABASE d ALLOW CONNECTIONS = false;
and
ALTER DATABASE d IS TEMPLATE = true;

This syntax matches that of CONNECTION LIMIT but unfortunately required
me to make ALLOW and CONNECTIONS unreserved keywords. I know we try not
to do that but I didn't see any other way. The two new options are of
course also available on CREATE DATABASE.

There is a slight change in behavior with this patch in that previously
one had to be superuser or have rolcatupdate appropriately set, and now
the owner of the database is also allowed to change these settings. I
believe this is for the better.

It was suggested to me that these options should either error out if
there are existing connections or terminate said connections. I don't
agree with that because there is no harm in connecting to a template
database (how else do you modify it?), and adding a reject rule in
pg_hba.conf doesn't disconnect existing users so why should turning off
ALLOW CONNECTIONS do it?

As for regression tests, I couldn't figure out how to make CREATE/ALTER
DATABASE play nice with make installcheck and so I haven't provided any.

Other than that, I think this patch is complete and so I'm adding it the
next commitfest.

--
Vik

Attachment Content-Type Size
database_attributes.v1.patch text/x-diff 15.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2014-05-24 04:03:43 Re: SQL access to database attributes
Previous Message David Rowley 2014-05-23 21:09:26 Re: Allowing join removals for more join types