2 doc/src/sgml/ref/create_type.sgml
3 PostgreSQL documentation
6 <refentry id="SQL-CREATETYPE">
8 <refentrytitle>CREATE TYPE</refentrytitle>
9 <manvolnum>7</manvolnum>
10 <refmiscinfo>SQL - Language Statements</refmiscinfo>
14 <refname>CREATE TYPE</refname>
15 <refpurpose>define a new data type</refpurpose>
18 <indexterm zone="sql-createtype">
19 <primary>CREATE TYPE</primary>
24 CREATE TYPE <replaceable class="parameter">name</replaceable> AS
25 ( [ <replaceable class="PARAMETER">attribute_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [ COLLATE <replaceable>collation</replaceable> ] [, ... ] ] )
27 CREATE TYPE <replaceable class="parameter">name</replaceable> AS ENUM
28 ( [ '<replaceable class="parameter">label</replaceable>' [, ... ] ] )
30 CREATE TYPE <replaceable class="parameter">name</replaceable> AS RANGE (
31 SUBTYPE = <replaceable class="parameter">subtype</replaceable>
32 [ , SUBTYPE_OPCLASS = <replaceable class="parameter">subtype_operator_class</replaceable> ]
33 [ , COLLATION = <replaceable class="parameter">collation</replaceable> ]
34 [ , CANONICAL = <replaceable class="parameter">canonical_function</replaceable> ]
35 [ , SUBTYPE_DIFF = <replaceable class="parameter">subtype_diff_function</replaceable> ]
38 CREATE TYPE <replaceable class="parameter">name</replaceable> (
39 INPUT = <replaceable class="parameter">input_function</replaceable>,
40 OUTPUT = <replaceable class="parameter">output_function</replaceable>
41 [ , RECEIVE = <replaceable class="parameter">receive_function</replaceable> ]
42 [ , SEND = <replaceable class="parameter">send_function</replaceable> ]
43 [ , TYPMOD_IN = <replaceable class="parameter">type_modifier_input_function</replaceable> ]
44 [ , TYPMOD_OUT = <replaceable class="parameter">type_modifier_output_function</replaceable> ]
45 [ , ANALYZE = <replaceable class="parameter">analyze_function</replaceable> ]
46 [ , INTERNALLENGTH = { <replaceable class="parameter">internallength</replaceable> | VARIABLE } ]
48 [ , ALIGNMENT = <replaceable class="parameter">alignment</replaceable> ]
49 [ , STORAGE = <replaceable class="parameter">storage</replaceable> ]
50 [ , LIKE = <replaceable class="parameter">like_type</replaceable> ]
51 [ , CATEGORY = <replaceable class="parameter">category</replaceable> ]
52 [ , PREFERRED = <replaceable class="parameter">preferred</replaceable> ]
53 [ , DEFAULT = <replaceable class="parameter">default</replaceable> ]
54 [ , ELEMENT = <replaceable class="parameter">element</replaceable> ]
55 [ , DELIMITER = <replaceable class="parameter">delimiter</replaceable> ]
56 [ , COLLATABLE = <replaceable class="parameter">collatable</replaceable> ]
59 CREATE TYPE <replaceable class="parameter">name</replaceable>
64 <title>Description</title>
67 <command>CREATE TYPE</command> registers a new data type for use in
68 the current database. The user who defines a type becomes its
73 If a schema name is given then the type is created in the specified
74 schema. Otherwise it is created in the current schema. The type
75 name must be distinct from the name of any existing type or domain
76 in the same schema. (Because tables have associated data types,
77 the type name must also be distinct from the name of any existing
78 table in the same schema.)
82 There are five forms of <command>CREATE TYPE</command>, as shown in the
83 syntax synopsis above. They respectively create a <firstterm>composite
84 type</>, an <firstterm>enum type</>, a <firstterm>range type</>, a
85 <firstterm>base type</>, or a <firstterm>shell type</>. The first four
86 of these are discussed in turn below. A shell type is simply a placeholder
87 for a type to be defined later; it is created by issuing <command>CREATE
88 TYPE</command> with no parameters except for the type name. Shell types
89 are needed as forward references when creating range types and base types,
90 as discussed in those sections.
94 <title>Composite Types</title>
97 The first form of <command>CREATE TYPE</command>
98 creates a composite type.
99 The composite type is specified by a list of attribute names and data types.
100 An attribute's collation can be specified too, if its data type is
101 collatable. A composite type is essentially the same as the row type
102 of a table, but using <command>CREATE TYPE</command> avoids the need to
103 create an actual table when all that is wanted is to define a type.
104 A stand-alone composite type is useful, for example, as the argument or
105 return type of a function.
109 To be able to create a composite type, you must
110 have <literal>USAGE</literal> privilege on all attribute types.
114 <refsect2 id="SQL-CREATETYPE-enum">
115 <title>Enumerated Types</title>
118 The second form of <command>CREATE TYPE</command> creates an enumerated
119 (enum) type, as described in <xref linkend="datatype-enum">.
120 Enum types take a list of one or more quoted labels, each of which
121 must be less than <symbol>NAMEDATALEN</symbol> bytes long (64 bytes in a
122 standard <productname>PostgreSQL</productname> build).
126 <refsect2 id="SQL-CREATETYPE-RANGE">
127 <title>Range Types</title>
130 The third form of <command>CREATE TYPE</command> creates a new
131 range type, as described in <xref linkend="rangetypes">.
135 The range type's <replaceable class="parameter">subtype</replaceable> can
136 be any type with an associated b-tree operator class (to determine the
137 ordering of values for the range type). Normally the subtype's default
138 b-tree operator class is used to determine ordering; to use a non-default
139 opclass, specify its name with <replaceable
140 class="parameter">subtype_opclass</replaceable>. If the subtype is
141 collatable, and you want to use a non-default collation in the range's
142 ordering, specify the desired collation with the <replaceable
143 class="parameter">collation</replaceable> option.
147 The optional <replaceable class="parameter">canonical</replaceable>
148 function must take one argument of the range type being defined, and
149 return a value of the same type. This is used to convert range values
150 to a canonical form, when applicable. See <xref
151 linkend="rangetypes-defining"> for more information. Creating a
152 <replaceable class="parameter">canonical</replaceable> function
153 is a bit tricky, since it must be defined before the range type can be
154 declared. To do this, you must first create a shell type, which is a
155 placeholder type that has no properties except a name and an
156 owner. This is done by issuing the command <literal>CREATE TYPE
157 <replaceable>name</></literal>, with no additional parameters. Then
158 the function can be declared using the shell type as argument and result,
159 and finally the range type can be declared using the same name. This
160 automatically replaces the shell type entry with a valid range type.
164 The optional <replaceable class="parameter">subtype_diff</replaceable>
165 function must take two values of the
166 <replaceable class="parameter">subtype</replaceable> type as argument,
167 and return a <type>double precision</type> value representing the
168 difference between the two given values. While this is optional,
169 providing it allows much greater efficiency of GiST indexes on columns of
170 the range type. See <xref linkend="rangetypes-defining"> for more
176 <title>Base Types</title>
179 The fourth form of <command>CREATE TYPE</command> creates a new base type
180 (scalar type). To create a new base type, you must be a superuser.
181 (This restriction is made because an erroneous type definition could
182 confuse or even crash the server.)
186 The parameters can appear in any order, not only that
187 illustrated above, and most are optional. You must register
188 two or more functions (using <command>CREATE FUNCTION</command>) before
189 defining the type. The support functions
190 <replaceable class="parameter">input_function</replaceable> and
191 <replaceable class="parameter">output_function</replaceable>
192 are required, while the functions
193 <replaceable class="parameter">receive_function</replaceable>,
194 <replaceable class="parameter">send_function</replaceable>,
195 <replaceable class="parameter">type_modifier_input_function</replaceable>,
196 <replaceable class="parameter">type_modifier_output_function</replaceable> and
197 <replaceable class="parameter">analyze_function</replaceable>
198 are optional. Generally these functions have to be coded in C
199 or another low-level language.
203 The <replaceable class="parameter">input_function</replaceable>
204 converts the type's external textual representation to the internal
205 representation used by the operators and functions defined for the type.
206 <replaceable class="parameter">output_function</replaceable>
207 performs the reverse transformation. The input function can be
208 declared as taking one argument of type <type>cstring</type>,
209 or as taking three arguments of types
210 <type>cstring</type>, <type>oid</type>, <type>integer</type>.
211 The first argument is the input text as a C string, the second
212 argument is the type's own OID (except for array types, which instead
213 receive their element type's OID),
214 and the third is the <literal>typmod</> of the destination column, if known
215 (-1 will be passed if not).
216 The input function must return a value of the data type itself.
217 Usually, an input function should be declared STRICT; if it is not,
218 it will be called with a NULL first parameter when reading a NULL
219 input value. The function must still return NULL in this case, unless
221 (This case is mainly meant to support domain input functions, which
222 might need to reject NULL inputs.)
223 The output function must be
224 declared as taking one argument of the new data type.
225 The output function must return type <type>cstring</type>.
226 Output functions are not invoked for NULL values.
230 The optional <replaceable class="parameter">receive_function</replaceable>
231 converts the type's external binary representation to the internal
232 representation. If this function is not supplied, the type cannot
233 participate in binary input. The binary representation should be
234 chosen to be cheap to convert to internal form, while being reasonably
235 portable. (For example, the standard integer data types use network
236 byte order as the external binary representation, while the internal
237 representation is in the machine's native byte order.) The receive
238 function should perform adequate checking to ensure that the value is
240 The receive function can be declared as taking one argument of type
241 <type>internal</type>, or as taking three arguments of types
242 <type>internal</type>, <type>oid</type>, <type>integer</type>.
243 The first argument is a pointer to a <type>StringInfo</type> buffer
244 holding the received byte string; the optional arguments are the
245 same as for the text input function.
246 The receive function must return a value of the data type itself.
247 Usually, a receive function should be declared STRICT; if it is not,
248 it will be called with a NULL first parameter when reading a NULL
249 input value. The function must still return NULL in this case, unless
251 (This case is mainly meant to support domain receive functions, which
252 might need to reject NULL inputs.)
253 Similarly, the optional
254 <replaceable class="parameter">send_function</replaceable> converts
255 from the internal representation to the external binary representation.
256 If this function is not supplied, the type cannot participate in binary
257 output. The send function must be
258 declared as taking one argument of the new data type.
259 The send function must return type <type>bytea</type>.
260 Send functions are not invoked for NULL values.
264 You should at this point be wondering how the input and output functions
265 can be declared to have results or arguments of the new type, when they
266 have to be created before the new type can be created. The answer is that
267 the type should first be defined as a <firstterm>shell type</>, which is a
268 placeholder type that has no properties except a name and an owner. This
269 is done by issuing the command <literal>CREATE TYPE
270 <replaceable>name</></literal>, with no additional parameters. Then the
271 I/O functions can be defined referencing the shell type. Finally,
272 <command>CREATE TYPE</> with a full definition replaces the shell entry
273 with a complete, valid type definition, after which the new type can be
279 <replaceable class="parameter">type_modifier_input_function</replaceable>
280 and <replaceable class="parameter">type_modifier_output_function</replaceable>
281 are needed if the type supports modifiers, that is optional constraints
282 attached to a type declaration, such as <literal>char(5)</> or
283 <literal>numeric(30,2)</>. <productname>PostgreSQL</productname> allows
284 user-defined types to take one or more simple constants or identifiers as
285 modifiers. However, this information must be capable of being packed into a
286 single non-negative integer value for storage in the system catalogs. The
287 <replaceable class="parameter">type_modifier_input_function</replaceable>
288 is passed the declared modifier(s) in the form of a <type>cstring</>
289 array. It must check the values for validity (throwing an error if they
290 are wrong), and if they are correct, return a single non-negative
291 <type>integer</> value that will be stored as the column <quote>typmod</>.
292 Type modifiers will be rejected if the type does not have a
293 <replaceable class="parameter">type_modifier_input_function</replaceable>.
294 The <replaceable class="parameter">type_modifier_output_function</replaceable>
295 converts the internal integer typmod value back to the correct form for
296 user display. It must return a <type>cstring</> value that is the exact
297 string to append to the type name; for example <type>numeric</>'s
298 function might return <literal>(30,2)</>.
299 It is allowed to omit the
300 <replaceable class="parameter">type_modifier_output_function</replaceable>,
301 in which case the default display format is just the stored typmod integer
302 value enclosed in parentheses.
306 The optional <replaceable class="parameter">analyze_function</replaceable>
307 performs type-specific statistics collection for columns of the data type.
308 By default, <command>ANALYZE</> will attempt to gather statistics using
309 the type's <quote>equals</> and <quote>less-than</> operators, if there
310 is a default b-tree operator class for the type. For non-scalar types
311 this behavior is likely to be unsuitable, so it can be overridden by
312 specifying a custom analysis function. The analysis function must be
313 declared to take a single argument of type <type>internal</>, and return
314 a <type>boolean</> result. The detailed API for analysis functions appears
315 in <filename>src/include/commands/vacuum.h</>.
319 While the details of the new type's internal representation are only
320 known to the I/O functions and other functions you create to work with
321 the type, there are several properties of the internal representation
322 that must be declared to <productname>PostgreSQL</productname>.
324 <replaceable class="parameter">internallength</replaceable>.
325 Base data types can be fixed-length, in which case
326 <replaceable class="parameter">internallength</replaceable> is a
327 positive integer, or variable length, indicated by setting
328 <replaceable class="parameter">internallength</replaceable>
329 to <literal>VARIABLE</literal>. (Internally, this is represented
330 by setting <literal>typlen</> to -1.) The internal representation of all
331 variable-length types must start with a 4-byte integer giving the total
332 length of this value of the type.
336 The optional flag <literal>PASSEDBYVALUE</literal> indicates that
337 values of this data type are passed by value, rather than by
338 reference. You cannot pass by value types whose internal
339 representation is larger than the size of the <type>Datum</> type
340 (4 bytes on most machines, 8 bytes on a few).
344 The <replaceable class="parameter">alignment</replaceable> parameter
345 specifies the storage alignment required for the data type. The
346 allowed values equate to alignment on 1, 2, 4, or 8 byte boundaries.
347 Note that variable-length types must have an alignment of at least
348 4, since they necessarily contain an <type>int4</> as their first component.
352 The <replaceable class="parameter">storage</replaceable> parameter
353 allows selection of storage strategies for variable-length data
354 types. (Only <literal>plain</literal> is allowed for fixed-length
355 types.) <literal>plain</literal> specifies that data of the type
356 will always be stored in-line and not compressed.
357 <literal>extended</literal> specifies that the system will first
358 try to compress a long data value, and will move the value out of
359 the main table row if it's still too long.
360 <literal>external</literal> allows the value to be moved out of the
361 main table, but the system will not try to compress it.
362 <literal>main</literal> allows compression, but discourages moving
363 the value out of the main table. (Data items with this storage
364 strategy might still be moved out of the main table if there is no
365 other way to make a row fit, but they will be kept in the main
366 table preferentially over <literal>extended</literal> and
367 <literal>external</literal> items.)
371 The <replaceable class="parameter">like_type</replaceable> parameter
372 provides an alternative method for specifying the basic representation
373 properties of a data type: copy them from some existing type. The values of
374 <replaceable class="parameter">internallength</replaceable>,
375 <replaceable class="parameter">passedbyvalue</replaceable>,
376 <replaceable class="parameter">alignment</replaceable>, and
377 <replaceable class="parameter">storage</replaceable> are copied from the
378 named type. (It is possible, though usually undesirable, to override
379 some of these values by specifying them along with the <literal>LIKE</>
380 clause.) Specifying representation this way is especially useful when
381 the low-level implementation of the new type <quote>piggybacks</> on an
382 existing type in some fashion.
386 The <replaceable class="parameter">category</replaceable> and
387 <replaceable class="parameter">preferred</replaceable> parameters can be
388 used to help control which implicit cast will be applied in ambiguous
389 situations. Each data type belongs to a category named by a single ASCII
390 character, and each type is either <quote>preferred</> or not within its
391 category. The parser will prefer casting to preferred types (but only from
392 other types within the same category) when this rule is helpful in
393 resolving overloaded functions or operators. For more details see <xref
394 linkend="typeconv">. For types that have no implicit casts to or from any
395 other types, it is sufficient to leave these settings at the defaults.
396 However, for a group of related types that have implicit casts, it is often
397 helpful to mark them all as belonging to a category and select one or two
398 of the <quote>most general</> types as being preferred within the category.
399 The <replaceable class="parameter">category</replaceable> parameter is
400 especially useful when adding a user-defined type to an existing built-in
401 category, such as the numeric or string types. However, it is also
402 possible to create new entirely-user-defined type categories. Select any
403 ASCII character other than an upper-case letter to name such a category.
407 A default value can be specified, in case a user wants columns of the
408 data type to default to something other than the null value.
409 Specify the default with the <literal>DEFAULT</literal> key word.
410 (Such a default can be overridden by an explicit <literal>DEFAULT</literal>
411 clause attached to a particular column.)
415 To indicate that a type is an array, specify the type of the array
416 elements using the <literal>ELEMENT</> key word. For example, to
417 define an array of 4-byte integers (<type>int4</type>), specify
418 <literal>ELEMENT = int4</literal>. More details about array types
423 To indicate the delimiter to be used between values in the external
424 representation of arrays of this type, <replaceable
425 class="parameter">delimiter</replaceable> can be
426 set to a specific character. The default delimiter is the comma
427 (<literal>,</literal>). Note that the delimiter is associated
428 with the array element type, not the array type itself.
432 If the optional Boolean
433 parameter <replaceable class="parameter">collatable</replaceable>
434 is true, column definitions and expressions of the type may carry
435 collation information through use of
436 the <literal>COLLATE</literal> clause. It is up to the
437 implementations of the functions operating on the type to actually
438 make use of the collation information; this does not happen
439 automatically merely by marking the type collatable.
444 <title>Array Types</title>
447 Whenever a user-defined type is created,
448 <productname>PostgreSQL</productname> automatically creates an
449 associated array type, whose name consists of the element type's
450 name prepended with an underscore, and truncated if necessary to keep
451 it less than <symbol>NAMEDATALEN</symbol> bytes long. (If the name
452 so generated collides with an existing type name, the process is
453 repeated until a non-colliding name is found.)
454 This implicitly-created array type is variable length and uses the
455 built-in input and output functions <literal>array_in</> and
456 <literal>array_out</>. The array type tracks any changes in its
457 element type's owner or schema, and is dropped if the element type is.
461 You might reasonably ask why there is an <option>ELEMENT</>
462 option, if the system makes the correct array type automatically.
463 The only case where it's useful to use <option>ELEMENT</> is when you are
464 making a fixed-length type that happens to be internally an array of a number of
465 identical things, and you want to allow these things to be accessed
466 directly by subscripting, in addition to whatever operations you plan
467 to provide for the type as a whole. For example, type <type>point</>
468 is represented as just two floating-point numbers, which it allows to be
469 accessed as <literal>point[0]</> and <literal>point[1]</>.
471 this facility only works for fixed-length types whose internal form
472 is exactly a sequence of identical fixed-length fields. A subscriptable
473 variable-length type must have the generalized internal representation
474 used by <literal>array_in</> and <literal>array_out</>.
475 For historical reasons (i.e., this is clearly wrong but it's far too
476 late to change it), subscripting of fixed-length array types starts from
477 zero, rather than from one as for variable-length arrays.
483 <title>Parameters</title>
487 <term><replaceable class="parameter">name</replaceable></term>
490 The name (optionally schema-qualified) of a type to be created.
496 <term><replaceable class="parameter">attribute_name</replaceable></term>
499 The name of an attribute (column) for the composite type.
505 <term><replaceable class="parameter">data_type</replaceable></term>
508 The name of an existing data type to become a column of the
515 <term><replaceable class="parameter">collation</replaceable></term>
518 The name of an existing collation to be associated with a column of
519 a composite type, or with a range type.
525 <term><replaceable class="parameter">label</replaceable></term>
528 A string literal representing the textual label associated with
529 one value of an enum type.
535 <term><replaceable class="parameter">subtype</replaceable></term>
538 The name of the element type that the range type will represent ranges
545 <term><replaceable class="parameter">subtype_operator_class</replaceable></term>
548 The name of a b-tree operator class for the subtype.
554 <term><replaceable class="parameter">canonical_function</replaceable></term>
557 The name of the canonicalization function for the range type.
563 <term><replaceable class="parameter">subtype_diff_function</replaceable></term>
566 The name of a difference function for the subtype.
572 <term><replaceable class="parameter">input_function</replaceable></term>
575 The name of a function that converts data from the type's
576 external textual form to its internal form.
582 <term><replaceable class="parameter">output_function</replaceable></term>
585 The name of a function that converts data from the type's
586 internal form to its external textual form.
592 <term><replaceable class="parameter">receive_function</replaceable></term>
595 The name of a function that converts data from the type's
596 external binary form to its internal form.
602 <term><replaceable class="parameter">send_function</replaceable></term>
605 The name of a function that converts data from the type's
606 internal form to its external binary form.
612 <term><replaceable class="parameter">type_modifier_input_function</replaceable></term>
615 The name of a function that converts an array of modifier(s) for the type
622 <term><replaceable class="parameter">type_modifier_output_function</replaceable></term>
625 The name of a function that converts the internal form of the type's
626 modifier(s) to external textual form.
632 <term><replaceable class="parameter">analyze_function</replaceable></term>
635 The name of a function that performs statistical analysis for the
642 <term><replaceable class="parameter">internallength</replaceable></term>
645 A numeric constant that specifies the length in bytes of the new
646 type's internal representation. The default assumption is that
647 it is variable-length.
653 <term><replaceable class="parameter">alignment</replaceable></term>
656 The storage alignment requirement of the data type. If specified,
657 it must be <literal>char</literal>, <literal>int2</literal>,
658 <literal>int4</literal>, or <literal>double</literal>; the
659 default is <literal>int4</literal>.
665 <term><replaceable class="parameter">storage</replaceable></term>
668 The storage strategy for the data type. If specified, must be
669 <literal>plain</literal>, <literal>external</literal>,
670 <literal>extended</literal>, or <literal>main</literal>; the
671 default is <literal>plain</literal>.
677 <term><replaceable class="parameter">like_type</replaceable></term>
680 The name of an existing data type that the new type will have the
681 same representation as. The values of
682 <replaceable class="parameter">internallength</replaceable>,
683 <replaceable class="parameter">passedbyvalue</replaceable>,
684 <replaceable class="parameter">alignment</replaceable>, and
685 <replaceable class="parameter">storage</replaceable>
686 are copied from that type, unless overridden by explicit
687 specification elsewhere in this <command>CREATE TYPE</> command.
693 <term><replaceable class="parameter">category</replaceable></term>
696 The category code (a single ASCII character) for this type.
697 The default is <literal>'U'</> for <quote>user-defined type</>.
698 Other standard category codes can be found in
699 <xref linkend="catalog-typcategory-table">. You may also choose
700 other ASCII characters in order to create custom categories.
706 <term><replaceable class="parameter">preferred</replaceable></term>
709 True if this type is a preferred type within its type category,
710 else false. The default is false. Be very careful about creating
711 a new preferred type within an existing type category, as this
712 could cause surprising changes in behavior.
718 <term><replaceable class="parameter">default</replaceable></term>
721 The default value for the data type. If this is omitted, the
728 <term><replaceable class="parameter">element</replaceable></term>
731 The type being created is an array; this specifies the type of
738 <term><replaceable class="parameter">delimiter</replaceable></term>
741 The delimiter character to be used between values in arrays made
748 <term><replaceable class="parameter">collatable</replaceable></term>
751 True if this type's operations can use collation information.
752 The default is false.
759 <refsect1 id="SQL-CREATETYPE-notes">
763 Because there are no restrictions on use of a data type once it's been
764 created, creating a base type or range type is tantamount to granting
765 public execute permission on the functions mentioned in the type definition.
767 not an issue for the sorts of functions that are useful in a type
768 definition. But you might want to think twice before designing a type
769 in a way that would require <quote>secret</> information to be used
770 while converting it to or from external form.
774 Before <productname>PostgreSQL</productname> version 8.3, the name of
775 a generated array type was always exactly the element type's name with one
776 underscore character (<literal>_</literal>) prepended. (Type names were
777 therefore restricted in length to one less character than other names.)
778 While this is still usually the case, the array type name may vary from
779 this in case of maximum-length names or collisions with user type names
780 that begin with underscore. Writing code that depends on this convention
781 is therefore deprecated. Instead, use
782 <structname>pg_type</>.<structfield>typarray</> to locate the array type
783 associated with a given type.
787 It may be advisable to avoid using type and table names that begin with
788 underscore. While the server will change generated array type names to
789 avoid collisions with user-given names, there is still risk of confusion,
790 particularly with old client software that may assume that type names
791 beginning with underscores always represent arrays.
795 Before <productname>PostgreSQL</productname> version 8.2, the shell-type
797 <literal>CREATE TYPE <replaceable>name</></literal> did not exist.
798 The way to create a new base type was to create its input function first.
799 In this approach, <productname>PostgreSQL</productname> will first see
800 the name of the new data type as the return type of the input function.
801 The shell type is implicitly created in this situation, and then it
802 can be referenced in the definitions of the remaining I/O functions.
803 This approach still works, but is deprecated and might be disallowed in
804 some future release. Also, to avoid accidentally cluttering
805 the catalogs with shell types as a result of simple typos in function
806 definitions, a shell type will only be made this way when the input
807 function is written in C.
811 In <productname>PostgreSQL</productname> versions before 7.3, it
812 was customary to avoid creating a shell type at all, by replacing the
813 functions' forward references to the type name with the placeholder
814 pseudotype <type>opaque</>. The <type>cstring</> arguments and
815 results also had to be declared as <type>opaque</> before 7.3. To
816 support loading of old dump files, <command>CREATE TYPE</> will
817 accept I/O functions declared using <type>opaque</>, but it will issue
818 a notice and change the function declarations to use the correct
825 <title>Examples</title>
828 This example creates a composite type and uses it in
829 a function definition:
831 CREATE TYPE compfoo AS (f1 int, f2 text);
833 CREATE FUNCTION getfoo() RETURNS SETOF compfoo AS $$
834 SELECT fooid, fooname FROM foo
840 This example creates an enumerated type and uses it in
843 CREATE TYPE bug_status AS ENUM ('new', 'open', 'closed');
854 This example creates a range type:
856 CREATE TYPE float8_range AS RANGE (subtype = float8, subtype_diff = float8mi);
861 This example creates the base data type <type>box</type> and then uses the
862 type in a table definition:
866 CREATE FUNCTION my_box_in_function(cstring) RETURNS box AS ... ;
867 CREATE FUNCTION my_box_out_function(box) RETURNS cstring AS ... ;
871 INPUT = my_box_in_function,
872 OUTPUT = my_box_out_function
875 CREATE TABLE myboxes (
883 If the internal structure of <type>box</type> were an array of four
884 <type>float4</> elements, we might instead use:
888 INPUT = my_box_in_function,
889 OUTPUT = my_box_out_function,
893 which would allow a box value's component numbers to be accessed
894 by subscripting. Otherwise the type behaves the same as before.
898 This example creates a large object type and uses it in
902 INPUT = lo_filein, OUTPUT = lo_fileout,
903 INTERNALLENGTH = VARIABLE
905 CREATE TABLE big_objs (
913 More examples, including suitable input and output functions, are
914 in <xref linkend="xtypes">.
918 <refsect1 id="SQL-CREATETYPE-compatibility">
919 <title>Compatibility</title>
922 The first form of the <command>CREATE TYPE</command> command, which
923 creates a composite type, conforms to the <acronym>SQL</> standard.
924 The other forms are <productname>PostgreSQL</productname>
925 extensions. The <command>CREATE TYPE</command> statement in
926 the <acronym>SQL</> standard also defines other forms that are not
927 implemented in <productname>PostgreSQL</>.
931 The ability to create a composite type with zero attributes is
932 a <productname>PostgreSQL</productname>-specific deviation from the
933 standard (analogous to the same case in <command>CREATE TABLE</command>).
937 <refsect1 id="SQL-CREATETYPE-see-also">
938 <title>See Also</title>
940 <simplelist type="inline">
941 <member><xref linkend="sql-altertype"></member>
942 <member><xref linkend="sql-createdomain"></member>
943 <member><xref linkend="sql-createfunction"></member>
944 <member><xref linkend="sql-droptype"></member>