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