mirror of
https://github.com/postgres/postgres.git
synced 2025-05-02 11:44:50 +03:00
Make UNKNOWN into an actual pseudo-type.
Previously, type "unknown" was labeled as a base type in pg_type, which perhaps had some sense to it because you were allowed to create tables with unknown-type columns. But now that we don't allow that, it makes more sense to label it a pseudo-type. This has the additional effects of forbidding use of "unknown" as a domain base type, cast source or target type, PL function argument or result type, or plpgsql local variable type; all of which seem like good holes to plug. Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
This commit is contained in:
parent
1e7c4bb004
commit
d8d32d9a56
@ -4660,6 +4660,10 @@ SELECT * FROM pg_attribute
|
||||
<primary>internal</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-pseudo">
|
||||
<primary>unknown</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-pseudo">
|
||||
<primary>opaque</primary>
|
||||
</indexterm>
|
||||
@ -4781,9 +4785,16 @@ SELECT * FROM pg_attribute
|
||||
<entry>Indicates that a function returns no value.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>unknown</></entry>
|
||||
<entry>Identifies a not-yet-resolved type, e.g. of an undecorated
|
||||
string literal.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>opaque</></entry>
|
||||
<entry>An obsolete type name that formerly served all the above purposes.</entry>
|
||||
<entry>An obsolete type name that formerly served many of the above
|
||||
purposes.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
@ -2579,7 +2579,7 @@ WHERE c.altitude > 500 AND c.tableoid = p.oid;
|
||||
|
||||
<para>
|
||||
Another way to get the same effect is to use the <type>regclass</>
|
||||
pseudo-type, which will print the table OID symbolically:
|
||||
alias type, which will print the table OID symbolically:
|
||||
|
||||
<programlisting>
|
||||
SELECT c.tableoid::regclass, c.name, c.altitude
|
||||
|
@ -26,7 +26,7 @@
|
||||
language such as C, using the version-1 interface, and registered
|
||||
with <productname>PostgreSQL</productname> as taking no arguments
|
||||
and returning the type <type>language_handler</type>. 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 <xref linkend="xfunc-c">.
|
||||
|
@ -668,7 +668,7 @@
|
||||
number of parameter symbols (<literal>$</><replaceable>n</>)
|
||||
used in the query string. Another special case is that a parameter's
|
||||
type can be specified as <type>void</> (that is, the OID of the
|
||||
<type>void</> pseudotype). This is meant to allow parameter symbols
|
||||
<type>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 <type>void</> parameter
|
||||
could be used, but if such a parameter symbol appears in a function's
|
||||
|
@ -762,7 +762,7 @@ SELECT * FROM vw_getfoo;
|
||||
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 <type>record</>. When such a function is used in
|
||||
the pseudo-type <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:
|
||||
|
@ -160,8 +160,8 @@ CREATE [ OR REPLACE ] FUNCTION
|
||||
</para>
|
||||
<para>
|
||||
Depending on the implementation language it might also be allowed
|
||||
to specify <quote>pseudotypes</> such as <type>cstring</>.
|
||||
Pseudotypes indicate that the actual argument type is either
|
||||
to specify <quote>pseudo-types</> such as <type>cstring</>.
|
||||
Pseudo-types indicate that the actual argument type is either
|
||||
incompletely specified, or outside the set of ordinary SQL data types.
|
||||
</para>
|
||||
<para>
|
||||
@ -199,7 +199,7 @@ CREATE [ OR REPLACE ] FUNCTION
|
||||
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 <quote>pseudotypes</> such as <type>cstring</>.
|
||||
to specify <quote>pseudo-types</> such as <type>cstring</>.
|
||||
If the function is not supposed to return a value, specify
|
||||
<type>void</> as the return type.
|
||||
</para>
|
||||
|
@ -824,7 +824,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
|
||||
In <productname>PostgreSQL</productname> 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 <type>opaque</>. The <type>cstring</> arguments and
|
||||
pseudo-type <type>opaque</>. The <type>cstring</> arguments and
|
||||
results also had to be declared as <type>opaque</> before 7.3. To
|
||||
support loading of old dump files, <command>CREATE TYPE</> will
|
||||
accept I/O functions declared using <type>opaque</>, but it will issue
|
||||
|
@ -490,8 +490,7 @@ CheckAttributeType(const char *attname,
|
||||
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
|
||||
|
@ -53,6 +53,6 @@
|
||||
*/
|
||||
|
||||
/* yyyymmddN */
|
||||
#define CATALOG_VERSION_NO 201701201
|
||||
#define CATALOG_VERSION_NO 201701251
|
||||
|
||||
#endif
|
||||
|
@ -418,7 +418,7 @@ DESCR("relative, limited-range time interval (Unix delta time)");
|
||||
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
|
||||
|
||||
|
@ -59,7 +59,7 @@ WHERE (p1.typtype = 'c' AND p1.typrelid = 0) OR
|
||||
-- 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'\\_%'
|
||||
@ -71,8 +71,7 @@ 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,
|
||||
|
@ -53,7 +53,7 @@ WHERE (p1.typtype = 'c' AND p1.typrelid = 0) OR
|
||||
-- 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
|
||||
|
Loading…
x
Reference in New Issue
Block a user