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


Sun, 21 Sep 2003 17:37:59 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Error message cleanup
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


Sun, 21 Sep 2003 17:51:54 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Error message cleanup
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>)

Wed, 24 Sep 2003 20:43:34 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: Error message cleanup
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

Thu, 25 Sep 2003 00:34:36 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Error message cleanup 
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


Thu, 25 Sep 2003 08:08:57 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Error message cleanup
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)

Thu, 25 Sep 2003 22:10:36 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: Error message cleanup
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

Fri, 26 Sep 2003 00:14:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Error message cleanup 
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


Fri, 26 Sep 2003 19:42:54 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Error message cleanup