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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
