Movatterモバイル変換


[0]ホーム

URL:



Facebook
Postgres Pro
Facebook
Downloads
36.2. ThePostgres Pro Type System
Prev UpChapter 36. ExtendingSQLHome Next

36.2. ThePostgres Pro Type System

Postgres Pro data types can be divided into base types, container types, domains, and pseudo-types.

36.2.2. Container Types

Postgres Pro has three kinds ofcontainer types, which are types that contain multiple values of other types. These are arrays, composites, and ranges.

Arrays can hold multiple values that are all of the same type. An array type is automatically created for each base type, composite type, range type, and domain type. But there are no arrays of arrays. So far as the type system is concerned, multi-dimensional arrays are the same as one-dimensional arrays. Refer toSection 8.15 for more information.

Composite types, or row types, are created whenever the user creates a table. It is also possible to useCREATE TYPE to define astand-alone composite type with no associated table. A composite type is simply a list of types with associated field names. A value of a composite type is a row or record of field values. Refer toSection 8.16 for more information.

A range type can hold two values of the same type, which are the lower and upper bounds of the range. Range types are user-created, although a few built-in ones exist. Refer toSection 8.17 for more information.

36.2.3. Domains

A domain is based on a particular underlying type and for many purposes is interchangeable with its underlying type. However, a domain can have constraints that restrict its valid values to a subset of what the underlying type would allow. Domains are created using theSQL commandCREATE DOMAIN. Refer toSection 8.18 for more information.

36.2.4. Pseudo-Types

There are a fewpseudo-types for special purposes. Pseudo-types cannot appear as columns of tables or components of container types, but they can be used to declare the argument and result types of functions. This provides a mechanism within the type system to identify special classes of functions.Table 8.27 lists the existing pseudo-types.

36.2.5. Polymorphic Types

Some pseudo-types of special interest are thepolymorphic types, which are used to declarepolymorphic functions. This powerful feature allows a single function definition to operate on many different data types, with the specific data type(s) being determined by the data types actually passed to it in a particular call. The polymorphic types are shown inTable 36.1. Some examples of their use appear inSection 36.5.10.

Table 36.1. Polymorphic Types

NameFamilyDescription
anyelementSimpleIndicates that a function accepts any data type
anyarraySimpleIndicates that a function accepts any array data type
anynonarraySimpleIndicates that a function accepts any non-array data type
anyenumSimpleIndicates that a function accepts any enum data type (seeSection 8.7)
anyrangeSimpleIndicates that a function accepts any range data type (seeSection 8.17)
anycompatibleCommonIndicates that a function accepts any data type, with automatic promotion of multiple arguments to a common data type
anycompatiblearrayCommonIndicates that a function accepts any array data type, with automatic promotion of multiple arguments to a common data type
anycompatiblenonarrayCommonIndicates that a function accepts any non-array data type, with automatic promotion of multiple arguments to a common data type
anycompatiblerangeCommonIndicates that a function accepts any range data type, with automatic promotion of multiple arguments to a common data type

Polymorphic arguments and results are tied to each other and are resolved to specific data types when a query calling a polymorphic function is parsed. When there is more than one polymorphic argument, the actual data types of the input values must match up as described below. If the function's result type is polymorphic, or it has output parameters of polymorphic types, the types of those results are deduced from the actual types of the polymorphic inputs as described below.

For thesimple family of polymorphic types, the matching and deduction rules work like this:

Each position (either argument or return value) declared asanyelement is allowed to have any specific actual data type, but in any given call they must all be thesame actual type. Each position declared asanyarray can have any array data type, but similarly they must all be the same type. And similarly, positions declared asanyrange must all be the same range type. Furthermore, if there are positions declaredanyarray and others declaredanyelement, the actual array type in theanyarray positions must be an array whose elements are the same type appearing in theanyelement positions. Similarly, if there are positions declaredanyrange and others declaredanyelement oranyarray, the actual range type in theanyrange positions must be a range whose subtype is the same type appearing in theanyelement positions and the same as the element type of theanyarray positions.anynonarray is treated exactly the same asanyelement, but adds the additional constraint that the actual type must not be an array type.anyenum is treated exactly the same asanyelement, but adds the additional constraint that the actual type must be an enum type.

Thus, when more than one argument position is declared with a polymorphic type, the net effect is that only certain combinations of actual argument types are allowed. For example, a function declared asequal(anyelement, anyelement) will take any two input values, so long as they are of the same data type.

When the return value of a function is declared as a polymorphic type, there must be at least one argument position that is also polymorphic, and the actual data type(s) supplied for the polymorphic arguments determine the actual result type for that call. For example, if there were not already an array subscripting mechanism, one could define a function that implements subscripting assubscript(anyarray, integer) returns anyelement. This declaration constrains the actual first argument to be an array type, and allows the parser to infer the correct result type from the actual first argument's type. Another example is that a function declared asf(anyarray) returns anyenum will only accept arrays of enum types.

In most cases, the parser can infer the actual data type for a polymorphic result type from arguments that are of a different polymorphic type in the same family; for exampleanyarray can be deduced fromanyelement or vice versa. An exception is that a polymorphic result of typeanyrange requires an argument of typeanyrange; it cannot be deduced fromanyarray oranyelement arguments. This is because there could be multiple range types with the same subtype.

Note thatanynonarray andanyenum do not represent separate type variables; they are the same type asanyelement, just with an additional constraint. For example, declaring a function asf(anyelement, anyenum) is equivalent to declaring it asf(anyenum, anyenum): both actual arguments have to be the same enum type.

For thecommon family of polymorphic types, the matching and deduction rules work approximately the same as for thesimple family, with one major difference: the actual types of the arguments need not be identical, so long as they can be implicitly cast to a single common type. The common type is selected following the same rules as forUNION and related constructs (seeSection 10.5). Selection of the common type considers the actual types ofanycompatible andanycompatiblenonarray inputs, the array element types ofanycompatiblearray inputs, and the range subtypes ofanycompatiblerange inputs. Ifanycompatiblenonarray is present then the common type is required to be a non-array type. Once a common type is identified, arguments inanycompatible andanycompatiblenonarray positions are automatically cast to that type, and arguments inanycompatiblearray positions are automatically cast to the array type for that type.

Since there is no way to select a range type knowing only its subtype, use ofanycompatiblerange requires that all arguments declared with that type have the same actual range type, and that that type's subtype agree with the selected common type, so that no casting of the range values is required. As withanyrange, use ofanycompatiblerange as a function result type requires that there be ananycompatiblerange argument.

Notice that there is noanycompatibleenum type. Such a type would not be very useful, since there normally are not any implicit casts to enum types, meaning that there would be no way to resolve a common type for dissimilar enum inputs.

Thesimple andcommon polymorphic families represent two independent sets of type variables. Consider for example

CREATE FUNCTION myfunc(a anyelement, b anyelement,                       c anycompatible, d anycompatible)RETURNS anycompatible AS ...

In an actual call of this function, the first two inputs must have exactly the same type. The last two inputs must be promotable to a common type, but this type need not have anything to do with the type of the first two inputs. The result will have the common type of the last two inputs.

A variadic function (one taking a variable number of arguments, as inSection 36.5.5) can be polymorphic: this is accomplished by declaring its last parameter asVARIADICanyarray orVARIADICanycompatiblearray. For purposes of argument matching and determining the actual result type, such a function behaves the same as if you had written the appropriate number ofanynonarray oranycompatiblenonarray parameters.


Prev Up Next
36.1. How Extensibility Works Home 36.3. User-Defined Functions
pdfepub
Go to Postgres Pro Standard 13
By continuing to browse this website, you agree to the use of cookies. Go toPrivacy Policy.

[8]ページ先頭

©2009-2025 Movatter.jp