From a585c20d12d0e22befc8308e9f8ccb6f54a5df69 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 12 Nov 2001 21:04:46 +0000 Subject: Tweak parser so that there is a defined representation for datatypes bpchar, bit, numeric with typmod -1. Alter format_type so that this representation is printed when the typmod is -1. This ensures that tables having such columns can be pg_dump'd and reloaded correctly. Also, remove the rather useless and non-SQL-compliant default precision and scale for type NUMERIC. A numeric column declared as such (with no precision/scale) will now have typmod -1 which means that numeric values of any precision/scale can be stored in it, without conversion to a uniform scale. This seems significantly more useful than the former behavior. Part of response to bug #513. --- doc/src/sgml/datatype.sgml | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 83ffcca2750..5a9e9277457 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -1,5 +1,5 @@ @@ -533,14 +533,18 @@ NUMERIC(precision, scale) NUMERIC(precision) - selects a scale of 0. Merely specifying + selects a scale of 0. Specifying NUMERIC - uses a default precision and scale, which is currently (30,6). - (The SQL standard requires a default scale of 0. We find this a - bit useless. If you're concerned about portability, always - specify the precision and scale explicitly.) + without any precision or scale creates a column in which numeric + values of any precision and scale can be stored, up to the implementation + limit on precision. A column of this kind will not coerce input + values to any particular scale, whereas numeric columns + with a declared scale will coerce input values to that scale. + (The SQL standard requires a default scale of 0, ie, coercion to + integer accuracy. We find this a bit useless. If you're concerned about + portability, always specify the precision and scale explicitly.) @@ -852,13 +856,17 @@ CREATE TABLE tablename ( The storage requirement for data of these types is 4 bytes plus the actual string, and in case of character plus the - padding. Long strings will actually be compressed by the system - automatically. In any case, the longest possible character string + padding. Long strings will be compressed by the system + automatically, so the physical requirement on-disk may be less. + In any case, the longest possible character string that can be stored is about 1 GB. (The maximum value that will be allowed for n in the data type declaration is - actually larger than that. It wouldn't be very useful to change + less than that. It wouldn't be very useful to change this because with multibyte character encodings the number of - characters and bytes can be quite different anyway.) + characters and bytes can be quite different anyway. If you desire + to store long strings with no specific upper limit, use text + or character varying without a length specifier, + rather than making up an arbitrary length limit.) @@ -916,7 +924,7 @@ SELECT b, char_length(b) FROM test2; Postgres. The name type exists only for storage of internal catalog names and is not intended for use by the general user. Its length - is currently defined as 32 bytes (31 characters plus terminator) + is currently defined as 32 bytes (31 usable characters plus terminator) but should be referenced using the macro NAMEDATALEN. The length is set at compile time (and is therefore adjustable for special uses); the default -- cgit v1.2.3