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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
