mirror of
https://github.com/postgres/postgres.git
synced 2025-07-27 12:41:57 +03:00
Implement types regprocedure, regoper, regoperator, regclass, regtype
per pghackers discussion. Add some more typsanity tests, and clean up some problems exposed thereby (broken or missing array types for some built-in types). Also, clean up loose ends from unknownin/out patch.
This commit is contained in:
Tom Lane
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/bki.sgml,v 1.10 2002/03/22 19:20:02 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/bki.sgml,v 1.11 2002/04/25 02:56:55 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="bki">
|
||||
@ -122,7 +122,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/bki.sgml,v 1.10 2002/03/22 19:20:02 petere
|
||||
storage. The following types are allowed: <type>bool</type>,
|
||||
<type>bytea</type>, <type>char</type> (1 byte),
|
||||
<type>name</type>, <type>int2</type>, <type>int2vector</type>,
|
||||
<type>int4</type>, <type>regproc</type>, <type>text</type>,
|
||||
<type>int4</type>, <type>regproc</type>, <type>regclass</type>,
|
||||
<type>regtype</type>, <type>text</type>,
|
||||
<type>oid</type>, <type>tid</type>, <type>xid</type>,
|
||||
<type>cid</type>, <type>oidvector</type>, <type>smgr</type>,
|
||||
<type>_int4</type> (array), <type>_aclitem</type> (array).
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.89 2002/04/21 18:58:00 thomas Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.90 2002/04/25 02:56:55 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="datatype">
|
||||
@ -172,12 +172,6 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.89 2002/04/21 18:58:00 th
|
||||
<entry>exact numeric with selectable precision</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>oid</type></entry>
|
||||
<entry></entry>
|
||||
<entry>object identifier</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>path</type></entry>
|
||||
<entry></entry>
|
||||
@ -2894,6 +2888,165 @@ SELECT SUBSTRING(b FROM 1 FOR 2) FROM test;
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="datatype-oid">
|
||||
<title>Object Identifier Types</title>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>object identifier</primary>
|
||||
<secondary>data type</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>oid</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>regproc</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>regprocedure</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>regoper</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>regoperator</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>regclass</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm zone="datatype-oid">
|
||||
<primary>regtype</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
Object identifiers (OIDs) are used internally by
|
||||
<productname>PostgreSQL</productname> as primary keys for various system
|
||||
tables. Also, an OID system column is added to user-created tables
|
||||
(unless <literal>WITHOUT OIDS</> is specified at table creation time).
|
||||
Type <type>oid</> represents an object identifier. There are also
|
||||
several aliases for <type>oid</>: <type>regproc</>, <type>regprocedure</>,
|
||||
<type>regoper</>, <type>regoperator</>, <type>regclass</>,
|
||||
and <type>regtype</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <type>oid</> type is currently implemented as an unsigned four-byte
|
||||
integer.
|
||||
Therefore, it is not large enough to provide database-wide uniqueness
|
||||
in large databases, or even in large individual tables. So, using a
|
||||
user-created table's OID column as a primary key is discouraged.
|
||||
OIDs are best used only for references to system tables.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <type>oid</> type itself has few operations beyond comparison
|
||||
(which is implemented as unsigned comparison). It can be cast to
|
||||
integer, however, and then manipulated using the standard integer
|
||||
operators. (Beware of possible signed-versus-unsigned confusion
|
||||
if you do this.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <type>oid</> alias types have no operations of their own except
|
||||
for specialized input and output routines. These routines are able
|
||||
to accept and display symbolic names for system objects, rather than
|
||||
the raw numeric value that type <type>oid</> would use. The alias
|
||||
types allow simplified lookup of OID values for objects: for example,
|
||||
one may write <literal>'mytable'::regclass</> to get the OID of table
|
||||
<literal>mytable</>, rather than <literal>SELECT oid FROM pg_class WHERE
|
||||
relname = 'mytable'</>. (In reality, a much more complicated SELECT would
|
||||
be needed to deal with selecting the right OID when there are multiple
|
||||
tables named <literal>mytable</> in different schemas.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<table tocentry="1">
|
||||
<title>Object Identifier Types</title>
|
||||
<tgroup cols="4">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Type name</entry>
|
||||
<entry>References</entry>
|
||||
<entry>Description</entry>
|
||||
<entry>Examples</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
|
||||
<row>
|
||||
<entry><type>oid</></entry>
|
||||
<entry>any</entry>
|
||||
<entry>Numeric object identifier</entry>
|
||||
<entry>564182</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>regproc</></entry>
|
||||
<entry>pg_proc</entry>
|
||||
<entry>Function name</entry>
|
||||
<entry>sum</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>regprocedure</></entry>
|
||||
<entry>pg_proc</entry>
|
||||
<entry>Function with argument types</entry>
|
||||
<entry>sum(int4)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>regoper</></entry>
|
||||
<entry>pg_operator</entry>
|
||||
<entry>Operator name</entry>
|
||||
<entry>+</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>regoperator</></entry>
|
||||
<entry>pg_operator</entry>
|
||||
<entry>Operator with argument types</entry>
|
||||
<entry>*(integer,integer) -(NONE,integer)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>regclass</></entry>
|
||||
<entry>pg_class</entry>
|
||||
<entry>Relation name</entry>
|
||||
<entry>pg_type</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>regtype</></entry>
|
||||
<entry>pg_type</entry>
|
||||
<entry>Type name</entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All of the alias types accept schema-qualified names, and will
|
||||
display schema-qualified names on output if the object would not
|
||||
be found in the current search path without being qualified.
|
||||
The <type>regproc</> and <type>regoper</> alias types will only
|
||||
accept input names that are unique (not overloaded), so they are
|
||||
of limited use; for most uses <type>regprocedure</> or
|
||||
<type>regoperator</> is more appropriate. For <type>regoperator</>,
|
||||
unary operators are identified by writing NONE for the unused
|
||||
operand.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
|
||||
Reference in New Issue
Block a user