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