Thread: Error message cleanup
I've looked through the messages in the backend and identified some areas that still deserve some cleanup. Below I list some issues that deserve some discussion or that deserve being remembered by other developers. id, oid, pid -> ID, OID, PID attribute -> column tuple -> row or row state, depending on context "transaction block" vs. "BEGIN/END transaction block" -> Both are used, I think the first one is better. "could not do something" vs. "failed to do something" vs. "doing something failed" -> I think we should settle on the first one. Spelling of type names in all-caps, e.g., '... has type UNKNOWN'. What is wrong with '... has type "unknown"', which would be consistent with other references to database objects. See also various uses of CSTRING, OPAQUE, NUMERIC, TIMESTAMP, etc. TEMP tables -> temporary tables sub-select -> subquery (SQL standard usage) Useless references to SQL syntax elements: "%s.nextval: reached MINVALUE (%s)". Better would be "nextval: reached maximum value of sequence \"%s\" (%s)". An appropriate use of SQL syntax elements would be "MINVALUE (%s) must be less than MAXVALUE (%s)". UNIQUE constraint -> unique constraint CHECK constraint -> check constraint NOT NULL constraint -> not-null constraint PRIMARY KEY constraint -> primary key constraint FOREIGN KEY constraint -> foreign key constraint Rationale: If you define a foreign key constraint, you don't necessarily use the key words FOREIGN KEY, so that usage has no basis and is in fact not used much right now. So the others should be consistent. The right side are perfectly valid phrases anyway, used for example in the SQL standard. coercion/conversion/cast: All of these are applied rather randomly to data types. The SQL standard uses the following terminology: Data is *cast* between different types. Strings are *converted* between different character sets. Collations of data are *coerced* to a common collation in an expression. These are fine by me; after all we already have CREATE CAST and CREATE CONVERSION. I also intend to change the descriptions of the GUC variables to start with a lowercase letter, because they are not sentences. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > > "transaction block" vs. "BEGIN/END transaction block" -> Both are used, I > think the first one is better. > I vote for the second one. Regards Gaetano Mendola
On Sun, Sep 21, 2003 at 05:37:59PM +0200, Peter Eisentraut wrote: > I've looked through the messages in the backend and identified some areas > that still deserve some cleanup. Below I list some issues that deserve > some discussion or that deserve being remembered by other developers. > > id, oid, pid -> ID, OID, PID > attribute -> column > tuple -> row or row state, depending on context Are you going to change "relation" to "table"? In most cases that is the intended meaning. ISTM in some other cases it refers to anything that can appear in pg_class, but I'm not 100% sure. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Are you going to change "relation" to "table"? In most cases that is
> the intended meaning. ISTM in some other cases it refers to anything
> that can appear in pg_class, but I'm not 100% sure.
Quite a lot of the code considers "relation" to mean "anything that has
a pg_class entry", which is a definition that's gotten fuzzier and
fuzzier as we've thrown more stuff into pg_class. (Standalone composite
types, for example, hardly qualify as a relation by anyone's
understanding of the term. But they have pg_class entries now.)
I don't mind rewording error messages to say "table" when in fact they
could only be referring to plain tables. But let's not just move the
fuzziness over from "relation" to "table".
regards, tom lane
Alvaro Herrera writes: > Are you going to change "relation" to "table"? In most cases that is > the intended meaning. ISTM in some other cases it refers to anything > that can appear in pg_class, but I'm not 100% sure. There are a few cases where it was obvious that only a table could be meant, but I didn't look really hard to find such places. I think there would be some merit to resolving the fuzziness surrounding the term "relation" before issuing messages to the user, but I'm unsure from which end to attack it. -- Peter Eisentraut peter_e@gmx.net
On Sun, Sep 21, 2003 at 05:37:59PM +0200, Peter Eisentraut wrote: > I've looked through the messages in the backend and identified some areas > that still deserve some cleanup. Below I list some issues that deserve > some discussion or that deserve being remembered by other developers. Regarding your message cleanup, I wonder about: #: rewrite/rewriteDefine.c:274 msgid "rules on SELECT rule must have action INSTEAD SELECT" Is this really the intended wording? #: utils/misc/guc.c:1318 msgid "log statement generating error at or above this level" Should this be "log statements", plural? -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Hay dos momentos en la vida de un hombre en los que no debería especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Sun, Sep 21, 2003 at 05:37:59PM +0200, Peter Eisentraut wrote:
> #: rewrite/rewriteDefine.c:274
> msgid "rules on SELECT rule must have action INSTEAD SELECT"
> Is this really the intended wording?
Seems like a typo to me too. Maybe "rules ON SELECT must have
action DO INSTEAD SELECT" ?
> #: utils/misc/guc.c:1318
> msgid "log statement generating error at or above this level"
> Should this be "log statements", plural?
I like the plural too: "log statements generating errors at or above
this level".
regards, tom lane
Alvaro Herrera writes: > Regarding your message cleanup, I wonder about: > > #: rewrite/rewriteDefine.c:274 > msgid "rules on SELECT rule must have action INSTEAD SELECT" > > Is this really the intended wording? > > #: utils/misc/guc.c:1318 > msgid "log statement generating error at or above this level" > > Should this be "log statements", plural? Both of these were mistakes. Thanks for pointing it out. -- Peter Eisentraut peter_e@gmx.net