Skip site navigation (1) Skip section navigation (2)

Opinions about wording of error messages for bug #3883?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org, pgtranslation-translators(at)pgfoundry(dot)org
Subject: Opinions about wording of error messages for bug #3883?
Date: 2008-01-30 00:40:46
Message-ID: 28827.1201653646@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
In the recent discussion of bug #3883 we decided that for safety's sake,
TRUNCATE, CLUSTER, and REINDEX ought to error out if there are any
active scans on the table (or index in the case of REINDEX).  This is
essentially the same as the test currently applied by ALTER TABLE,
which uses this code:

static void
CheckTableNotInUse(Relation rel)
{
    int            expected_refcnt;

    expected_refcnt = rel->rd_isnailed ? 2 : 1;
    if (rel->rd_refcnt != expected_refcnt)
        ereport(ERROR,
                (errcode(ERRCODE_OBJECT_IN_USE),
                 errmsg("relation \"%s\" is being used by active queries in this session",
                        RelationGetRelationName(rel))));

    if (AfterTriggerPendingOnRel(RelationGetRelid(rel)))
        ereport(ERROR,
                (errcode(ERRCODE_OBJECT_IN_USE),
                 errmsg("cannot alter table \"%s\" because it has pending trigger events",
                        RelationGetRelationName(rel))));
}

I would like to export this routine and have it be used by all four
commands, instead of duplicating this logic everywhere.  However,
that brings up the question of whether the error messages are
generic enough for all four commands; and if not, how we want them
to read.  I'm tempted to rephrase both messages along the line of

	cannot %s \"%s\" because ...

where the first %s is replaced by a SQL command name, viz ALTER TABLE,
CLUSTER, etc.  I'm not sure how nice this is for translation though.

Also, with 8.3 release being so close, it's likely that any change would
not get reflected into translations before release.  I don't think
that's a showstopper because these messages should hardly ever be seen
by normal users anyway; but maybe it's a consideration.

Comments, better ideas?

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-01-30 00:56:23
Subject: Re: Opinions about wording of error messages for bug#3883?
Previous:From: Neil ConwayDate: 2008-01-29 22:42:58
Subject: Win32: Building with Longhorn SDK

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group