1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-15 19:21:59 +03:00

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.
This commit is contained in:
Tom Lane
2001-11-12 21:04:46 +00:00
parent 9c9ea41b3c
commit a585c20d12
4 changed files with 57 additions and 57 deletions

View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.68 2001/11/08 23:36:55 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.69 2001/11/12 21:04:45 tgl Exp $
-->
<chapter id="datatype">
@ -533,14 +533,18 @@ NUMERIC(<replaceable>precision</replaceable>, <replaceable>scale</replaceable>)
<programlisting>
NUMERIC(<replaceable>precision</replaceable>)
</programlisting>
selects a scale of 0. Merely specifying
selects a scale of 0. Specifying
<programlisting>
NUMERIC
</programlisting>
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 <type>numeric</type> 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.)
</para>
<para>
@ -852,13 +856,17 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
<para>
The storage requirement for data of these types is 4 bytes plus
the actual string, and in case of <type>character</type> 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 <replaceable>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 <type>text</type>
or <type>character varying</type> without a length specifier,
rather than making up an arbitrary length limit.)
</para>
<tip>
@ -916,7 +924,7 @@ SELECT b, char_length(b) FROM test2;
<productname>Postgres</productname>. The <type>name</type> type
exists <emphasis>only</emphasis> 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
<symbol>NAMEDATALEN</symbol>. The length is set at compile time
(and is therefore adjustable for special uses); the default