Movatterモバイル変換


[0]ホーム

URL:



Facebook
Postgres Pro
Facebook
Downloads
34.2. ThePostgres Pro Type System
Prev UpChapter 34. ExtendingSQLHome Next

34.2. ThePostgres Pro Type System

Postgres Pro data types are divided into base types, composite types, domains, and pseudo-types.

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. The user can access the component fields fromSQL queries. Refer toSection 8.16 for more information on composite types.

34.2.3. Domains

A domain is based on a particular base type and for many purposes is interchangeable with its base type. However, a domain can have constraints that restrict its valid values to a subset of what the underlying base type would allow.

Domains can be created using theSQL commandCREATE DOMAIN. Their creation and use is not discussed in this chapter.

34.2.4. Pseudo-Types

There are a fewpseudo-types for special purposes. Pseudo-types cannot appear as columns of tables or attributes of composite 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.25 lists the existing pseudo-types.

34.2.5. Polymorphic Types

Five pseudo-types of special interest areanyelement,anyarray,anynonarray,anyenum, andanyrange, which are collectively calledpolymorphic types. Any function declared using these types is said to be apolymorphic function. A polymorphic function can 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.

Polymorphic arguments and results are tied to each other and are resolved to a specific data type when a query calling a polymorphic function is parsed. 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 supplied as the argument determines 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; for exampleanyarray can be deduced fromanyelement or vice versa. The 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.

A variadic function (one taking a variable number of arguments, as inSection 34.4.5) can be polymorphic: this is accomplished by declaring its last parameter asVARIADICanyarray. 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 parameters.


Prev Home Next
34.1. How Extensibility Works Up 34.3. User-defined Functions
pdfepub
Go to Postgres Pro Standard 9.6
By continuing to browse this website, you agree to the use of cookies. Go toPrivacy Policy.

[8]ページ先頭

©2009-2025 Movatter.jp