Support arrays of composite types, including the rowtypes of regular …

…tables

and views (but not system catalogs, nor sequences or toast tables).  Get rid
of the hardwired convention that a type's array type is named exactly "_type",
instead using a new column pg_type.typarray to provide the linkage.  (It still
will be named "_type", though, except in odd corner cases such as
maximum-length type names.)

Along the way, make tracking of owner and schema dependencies for types more
uniform: a type directly created by the user has these dependencies, while a
table rowtype or auto-generated array type does not have them, but depends on
its parent object instead.

David Fetter, Andrew Dunstan, Tom Lane

doc/src/sgml/array.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.60 2007/04/06 19:22:38 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.61 2007/05/11 17:57:11 tgl Exp $ -->
 
 <sect1 id="arrays">
  <title>Arrays</title>
@@ -10,8 +10,9 @@
  <para>
   <productname>PostgreSQL</productname> allows columns of a table to be
   defined as variable-length multidimensional arrays. Arrays of any
-  built-in or user-defined base type or enum type can be created.
-  (Arrays of composite types or domains are not yet supported, however.)
+  built-in or user-defined base type, enum type, or composite type
+  can be created.
+  Arrays of domains are not yet supported.
  </para>
 
  <sect2>

doc/src/sgml/catalogs.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.150 2007/04/06 22:33:41 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.151 2007/05/11 17:57:11 tgl Exp $ -->
 <!--
  Documentation of the system catalogs, directed toward PostgreSQL developers
  -->
@@ -4524,6 +4524,17 @@
       </entry>
      </row>
 
+     <row>
+      <entry><structfield>typarray</structfield></entry>
+      <entry><type>oid</type></entry>
+      <entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
+      <entry>
+       If <structfield>typarray</structfield> is not 0 then it
+       identifies another row in <structname>pg_type</structname>, which
+       is the <quote>true</quote> array type having this type as element
+      </entry>
+     </row>
+
      <row>
       <entry><structfield>typinput</structfield></entry>
       <entry><type>regproc</type></entry>
@@ -4686,9 +4697,10 @@
       <entry></entry>
       <entry><para>
        <structfield>typndims</structfield> is the number of array dimensions
-       for a domain that is an array (that is, <structfield>typbasetype</> is an array type;
-       the domain's <structfield>typelem</> will match the base type's <structfield>typelem</structfield>).
-       Zero for types other than array domains
+       for a domain that is an array (that is, <structfield>typbasetype</> is
+       an array type; the domain's <structfield>typelem</> will match the base
+       type's <structfield>typelem</structfield>).
+       Zero for types other than domains over array types
        </para></entry>
      </row>
 

doc/src/sgml/ref/create_type.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/create_type.sgml,v 1.69 2007/04/02 03:49:37 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/create_type.sgml,v 1.70 2007/05/11 17:57:11 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -312,15 +312,17 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
    <title>Array Types</title>
 
    <para>
-    Whenever a user-defined base or enum data type is created,
+    Whenever a user-defined type is created,
     <productname>PostgreSQL</productname> automatically creates an
     associated array type, whose name consists of the base type's
-    name prepended with an underscore.  The parser understands this
-    naming convention, and translates requests for columns of type
-    <literal>foo[]</> into requests for type <literal>_foo</>.
-    The implicitly-created array type is variable length and uses the
+    name prepended with an underscore, and truncated if necessary to keep
+    it less than <symbol>NAMEDATALEN</symbol> bytes long.  (If the name
+    so generated collides with an existing type name, the process is
+    repeated until a non-colliding name is found.)
+    This implicitly-created array type is variable length and uses the
     built-in input and output functions <literal>array_in</> and
-    <literal>array_out</>.
+    <literal>array_out</>.  The array type tracks any changes in its
+    element type's owner or schema, and is dropped if the element type is.
    </para>
 
    <para>
@@ -330,10 +332,9 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
     making a fixed-length type that happens to be internally an array of a number of
     identical things, and you want to allow these things to be accessed
     directly by subscripting, in addition to whatever operations you plan
-    to provide for the type as a whole.  For example, type <type>name</>
-    allows its constituent <type>char</> elements to be accessed this way.
-    A 2-D <type>point</> type could allow its two component numbers to be
-    accessed like <literal>point[0]</> and <literal>point[1]</>.
+    to provide for the type as a whole.  For example, type <type>point</>
+    is represented as just two floating-point numbers, which it allows to be
+    accessed as <literal>point[0]</> and <literal>point[1]</>.
     Note that
     this facility only works for fixed-length types whose internal form
     is exactly a sequence of identical fixed-length fields.  A subscriptable
@@ -529,12 +530,15 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
   <title>Notes</title>
 
   <para>
-   User-defined type names should not begin with the underscore character
-   (<literal>_</literal>) and should only be 62 characters
-   long (or in general <symbol>NAMEDATALEN</symbol> - 2, rather than
-   the <symbol>NAMEDATALEN</symbol> - 1 characters allowed for other
-   names).  Type names beginning with underscore are reserved for
-   internally-created array type names.
+   It is best to avoid using type names that begin with the underscore
+   character (<literal>_</literal>).  <productname>PostgreSQL</productname>
+   forms the name of an array type by prepending one or more underscores
+   to the element type's name, and these names may collide with user-defined
+   type names that begin with underscore.  While the system will modify
+   generated array type names to avoid collisions, this does not help if the
+   conflicting array type already exists when you try to create your type.
+   Also, various old client software may assume that names beginning with
+   underscores always represent arrays.
   </para>
 
   <para>

doc/src/sgml/syntax.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.117 2007/02/20 14:04:50 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.118 2007/05/11 17:57:11 tgl Exp $ -->
 
 <chapter id="sql-syntax">
  <title>SQL Syntax</title>
@@ -131,10 +131,10 @@ INSERT INTO MY_TABLE VALUES (3, 'hi there');
    <para>
     <indexterm><primary>identifier</primary><secondary>length</secondary></indexterm>
     The system uses no more than <symbol>NAMEDATALEN</symbol>-1
-    characters of an identifier; longer names can be written in
+    bytes of an identifier; longer names can be written in
     commands, but they will be truncated.  By default,
     <symbol>NAMEDATALEN</symbol> is 64 so the maximum identifier
-    length is 63. If this limit is problematic, it can be raised by
+    length is 63 bytes. If this limit is problematic, it can be raised by
     changing the <symbol>NAMEDATALEN</symbol> constant in
     <filename>src/include/pg_config_manual.h</filename>.
    </para>

src/backend/catalog/README

@@ -1,4 +1,4 @@
-$PostgreSQL: pgsql/src/backend/catalog/README,v 1.10 2006/07/31 01:16:36 tgl Exp $
+$PostgreSQL: pgsql/src/backend/catalog/README,v 1.11 2007/05/11 17:57:11 tgl Exp $
 
 This directory contains .c files that manipulate the system catalogs;
 src/include/catalog contains the .h files that define the structure
@@ -86,9 +86,9 @@ general) assumes that the fixed-length portions of all system catalog
 tuples are in fact present, because it maps C struct declarations onto
 them.  Thus, the variable-length fields must all be at the end, and
 only the variable-length fields of a catalog tuple are permitted to be
-NULL.  For example, if you set pg_type.typdelim to be NULL, a
-piece of code will likely perform "typetup->typdelim" (or, worse,
-"typetyp->typelem", which follows typdelim).  This will result in
+NULL.  For example, if you set pg_type.typrelid to be NULL, a
+piece of code will likely perform "typetup->typrelid" (or, worse,
+"typetyp->typelem", which follows typrelid).  This will result in
 random errors or even segmentation violations.  Hence, do NOT insert
 catalog tuples that contain NULL attributes except in their
 variable-length portions!  (The bootstrapping code is fairly good about