Skip site navigation (1) Skip section navigation (2)

Re: updated WIP: arrays of composites

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, David Fetter <david(at)fetter(dot)org>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: updated WIP: arrays of composites
Date: 2007-05-11 18:12:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Andrew Dunstan <andrew(at)dunslane(dot)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);
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

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-05-11 18:27:49
Subject: Re: [PATCHES] Arrays of Complex Types
Previous:From: Bruce MomjianDate: 2007-05-11 17:15:48
Subject: Re: Diagnostic functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group