On 21/06/2012 10:20 PM, Sergey Konoplev wrote:
On Thu, Jun 21, 2012 at 2:03 PM, Evan Martin
<postgre...@realityexists.net> wrote:
1) The workaround requires extra work for each developer (or at least each
client application) using PostgreSQL, while a fix in PostgreSQL would solve
this once and for all.
It is not clean what database you need to reconnect automatically
after the dropping. Moreover you may not have permissions to connect
other databases.
That's a fair point, so perhaps DROP DATABASE should still fail if the
/current/ connection is to that database (preferably with a helpful
error like "you cannot drop the database you are connected to"). There
should be an easy way to close all /other/ connections to it, though.
2) The workaround requires superuser privileges, which I don't think should
be required to drop your own database.
It does not require it. You might also be an owner to drop the database.
It does when I try it:
SELECT pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE datname = 'dropme';
ERROR: must be superuser to signal other server processes
In this case the user was the owner of "dropme", but another user was
also connected to it. I believe that should not stop the owner from
dropping their database.
Regards,
Evan
