Doc: explicitly point out that enum values can't be dropped.

This was not stated in so many words anywhere.  Document it to make
clear that it's a design limitation and not just an oversight or
documentation omission.

Discussion: https://postgr.es/m/152089733343.1222.6927268289645380498@wrigleys.postgresql.org
This commit is contained in:
Tom Lane 2018-03-16 13:44:34 -04:00
parent 4120864b9e
commit 013c0baadd
1 changed files with 14 additions and 6 deletions

View File

@ -3059,6 +3059,20 @@ SELECT person.name, holidays.num_weeks FROM person, holidays
<sect2> <sect2>
<title>Implementation Details</title> <title>Implementation Details</title>
<para>
Enum labels are case sensitive, so
<type>'happy'</type> is not the same as <type>'HAPPY'</type>.
White space in the labels is significant too.
</para>
<para>
Although enum types are primarily intended for static sets of values,
there is support for adding new values to an existing enum type, and for
renaming values (see <xref linkend="sql-altertype"/>). Existing values
cannot be removed from an enum type, nor can the sort ordering of such
values be changed, short of dropping and re-creating the enum type.
</para>
<para> <para>
An enum value occupies four bytes on disk. The length of an enum An enum value occupies four bytes on disk. The length of an enum
value's textual label is limited by the <symbol>NAMEDATALEN</symbol> value's textual label is limited by the <symbol>NAMEDATALEN</symbol>
@ -3066,12 +3080,6 @@ SELECT person.name, holidays.num_weeks FROM person, holidays
builds this means at most 63 bytes. builds this means at most 63 bytes.
</para> </para>
<para>
Enum labels are case sensitive, so
<type>'happy'</type> is not the same as <type>'HAPPY'</type>.
White space in the labels is significant too.
</para>
<para> <para>
The translations from internal enum values to textual labels are The translations from internal enum values to textual labels are
kept in the system catalog kept in the system catalog