Re: updated WIP: arrays of composites

TODO marked as done:

        o -Add support for arrays of complex types

I assume this is _not_ done, as stated below:

        o Add support for arrays of domains

I will add a URL for this item:

    http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php

---------------------------------------------------------------------------

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> >>> Attached is my rework of David Fetter's array of composites patch. It
> >>> has all the agreed modifications and checks, except altering the name
> >>> mangling.
>
> Applied with revisions.  There are some loose ends yet:
>
> * I didn't do anything about arrays of domains.  Although I think they'd
> basically work, there's one nasty fly in the ointment, which is ALTER
> DOMAIN ADD CONSTRAINT.  get_rels_with_domain() is not smart enough to
> detect arrays of domains, and its callers are not nearly smart enough to
> apply their checks to arrays.  So I think this had better wait for 8.4.
>
> BTW, I realized there's an existing bug here as of 8.2: when I enabled
> domains over domains I didn't do anything with get_rels_with_domain().
> Fortunately this is a relatively easy thing to deal with, we can just
> recurse to find columns of derived domain types, which the callers don't
> really need to treat any differently than they do now.  I'll go fix
> that part.
>
> * The feature leaves something to be desired in terms of usability,
> because array[row()] doesn't work:
>
> regression=# create type foo as (f1 int, f2 int);
> CREATE TYPE
> regression=# create table bar (ff1 foo[]);
> CREATE TABLE
> regression=# insert into bar values(array[row(1,2),row(3,4)]);
> ERROR:  could not find array type for data type record
> regression=#
>
> You can only get it to work if you plaster ::foo onto *each* row()
> construct.  Ugh.  This didn't seem trivial to improve.
>
> * I'm a bit concerned about dump order.  If a user wants to create
> types named "foo" and "_foo", he can, but it will only work if he
> makes "_foo" first --- else the derived type for foo is in the way.
> Since pg_dump has no clue about that constraint, it might easily
> dump "foo" first leading to an unrestorable dump.  The most usable
> solution would be to auto-rename previously created array types,
> but I dunno how implementable that would be.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +