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
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
* 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);
regression=# create table bar (ff1 foo);
regression=# insert into bar values(array[row(1,2),row(3,4)]);
ERROR: could not find array type for data type record
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