+
+
+
Indicates that a function returns no value.
+ |
+ unknown
+ Identifies a not-yet-resolved type, e.g. of an undecorated
+ string literal.
+
+
|
opaque
- An obsolete type name that formerly served all the above purposes.
+ An obsolete type name that formerly served many of the above
+ purposes.
Another way to get the same effect is to use the regclass
- pseudo-type, which will print the table OID symbolically:
+ alias type, which will print the table OID symbolically:
SELECT c.tableoid::regclass, c.name, c.altitude
language such as C, using the version-1 interface, and registered
with
PostgreSQL as taking no arguments
and returning the type language_handler. This
- special pseudotype identifies the function as a call handler and
+ special pseudo-type identifies the function as a call handler and
prevents it from being called directly in SQL commands.
For more details on C language calling conventions and dynamic loading,
see .
number of parameter symbols ($n)
used in the query string. Another special case is that a parameter's
type can be specified as void (that is, the OID of the
- void pseudotype). This is meant to allow parameter symbols
+ void pseudo-type). This is meant to allow parameter symbols
to be used for function parameters that are actually OUT parameters.
Ordinarily there is no context in which a void parameter
could be used, but if such a parameter symbol appears in a function's
In some cases it is useful to define table functions that can
return different column sets depending on how they are invoked.
To support this, the table function can be declared as returning
- the pseudotype record. When such a function is used in
+ the pseudo-type record. When such a function is used in
a query, the expected row structure must be specified in the
query itself, so that the system can know how to parse and plan
the query. This syntax looks like:
Depending on the implementation language it might also be allowed
- to specify pseudotypes such as cstring.
- Pseudotypes indicate that the actual argument type is either
+ to specify pseudo-types such as cstring.
+ Pseudo-types indicate that the actual argument type is either
incompletely specified, or outside the set of ordinary SQL data types.
can be a base, composite, or domain type,
or can reference the type of a table column.
Depending on the implementation language it might also be allowed
- to specify pseudotypes such as cstring.
+ to specify pseudo-types such as cstring.
If the function is not supposed to return a value, specify
void as the return type.
In
PostgreSQL versions before 7.3, it
was customary to avoid creating a shell type at all, by replacing the
functions' forward references to the type name with the placeholder
- pseudotype opaque. The cstring arguments and
+ pseudo-type opaque. The cstring arguments and
results also had to be declared as opaque before 7.3. To
support loading of old dump files, CREATE TYPE will
accept I/O functions declared using opaque, but it will issue
char att_typtype = get_typtype(atttypid);
Oid att_typelem;
- if (atttypid == UNKNOWNOID ||
- att_typtype == TYPTYPE_PSEUDO)
+ if (att_typtype == TYPTYPE_PSEUDO)
{
/*
* Refuse any attempt to create a pseudo-type column, except for a
*/
/* yyyymmddN */
-#define CATALOG_VERSION_NO 201701201
+#define CATALOG_VERSION_NO 201701251
#endif
DATA(insert OID = 704 ( tinterval PGNSP PGUID 12 f b T f t \054 0 0 1025 tintervalin tintervalout tintervalrecv tintervalsend - - - i p f 0 -1 0 0 _null_ _null_ _null_ ));
DESCR("(abstime,abstime), time interval");
#define TINTERVALOID 704
-DATA(insert OID = 705 ( unknown PGNSP PGUID -2 f b X f t \054 0 0 0 unknownin unknownout unknownrecv unknownsend - - - c p f 0 -1 0 0 _null_ _null_ _null_ ));
+DATA(insert OID = 705 ( unknown PGNSP PGUID -2 f p X f t \054 0 0 0 unknownin unknownout unknownrecv unknownsend - - - c p f 0 -1 0 0 _null_ _null_ _null_ ));
DESCR("");
#define UNKNOWNOID 705
-- Look for types that should have an array type according to their typtype,
-- but don't. We exclude composites here because we have not bothered to
-- make array types corresponding to the system catalogs' rowtypes.
--- NOTE: as of 9.1, this check finds pg_node_tree, smgr, and unknown.
+-- NOTE: as of v10, this check finds pg_node_tree and smgr.
SELECT p1.oid, p1.typname
FROM pg_type as p1
WHERE p1.typtype not in ('c','d','p') AND p1.typname NOT LIKE E'\\_%'
-----+--------------
194 | pg_node_tree
210 | smgr
- 705 | unknown
-(3 rows)
+(2 rows)
-- Make sure typarray points to a varlena array type of our own base
SELECT p1.oid, p1.typname as basetype, p2.typname as arraytype,
-- Look for types that should have an array type according to their typtype,
-- but don't. We exclude composites here because we have not bothered to
-- make array types corresponding to the system catalogs' rowtypes.
--- NOTE: as of 9.1, this check finds pg_node_tree, smgr, and unknown.
+-- NOTE: as of v10, this check finds pg_node_tree and smgr.
SELECT p1.oid, p1.typname
FROM pg_type as p1
projects / postgresql.git / commitdiff