Re: DROP DATABASE always seeing database in use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jens-Wolfhard Schicke <drahflow(at)gmx(dot)de>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DROP DATABASE always seeing database in use
Date: 2008-08-05 05:41:14
Message-ID: 139.1217914874@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jens-Wolfhard Schicke <drahflow(at)gmx(dot)de> writes:
> Tom Lane wrote:
>> ERROR: database "%s" is being accessed by other users
>> DETAIL: There are %d session(s) and %d prepared transaction(s) using the database.
>>
>> I'm aware that this phrasing might not translate very nicely ... anyone
>> have a suggestion for better wording?

> I can only estimate translation effort into German, but how about:

> DETAIL: Active users of the database: %d session(s), %d prepared transaction(s)

Hmmm ... what I ended up committing was code that special-cased the
common cases where you only have one or the other, ie

/*
* We don't worry about singular versus plural here, since the English
* rules for that don't translate very well. But we can at least avoid
* the case of zero items.
*/
if (notherbackends > 0 && npreparedxacts > 0)
errdetail("There are %d other session(s) and %d prepared transaction(s) using the database.",
notherbackends, npreparedxacts);
else if (notherbackends > 0)
errdetail("There are %d other session(s) using the database.",
notherbackends);
else
errdetail("There are %d prepared transaction(s) using the database.",
npreparedxacts);

Your proposal seems fine for the first case but a bit stilted for the
other two. Or maybe that's just me.

Of course, we don't *have* to do it as above at all, if "0 prepared
transactions" doesn't bother people.

Ideas anybody?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2008-08-05 06:21:06 PL/LOLCODE [was Re: [PATCH] "\ef <function>" in psql]
Previous Message Nick 2008-08-05 03:39:33 Reliability of CURRVAL in a RULE