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
