On Sat, Mar 03, 2007 at 09:06:11AM -0500, Andrew Dunstan wrote:
>
>
> Martijn van Oosterhout wrote:
> >On Fri, Mar 02, 2007 at 06:42:14PM -0600, Andrew Dunstan wrote:
> >
> >>>I'm still not happy about the idea of doing this for every relation
> >>>(and doing it for sequences and indexes would be the height of
> >>>wastefulness). How about we only do it for composite types?
> >>>
> >>I'm not happy about that. I agree that indexes and sequences should not be
> >>done, but can we please do plain table types? I would be OK if we skipped
> >>catalog tables, if that would make you happier.
> >>
> >
> >Two thoughts:
> >
> >1. Make the array types only when someone actually uses them (create a
> >table with it or something).
This doesn't sound so great.
> >2. Make a command: CREATE TYPE ARRAY OF "foo";
> >
> >The latter has the benefit of not restricting it to an arbitrary choice
> >of types, you could accept both domains and composite types here.
I'm thinking that DOMAINs over simple types should just automatically
get corresponding array types. We don't yet support DOMAINs over
complex types, but when we do, whatever we do with arrays of regular
complex types should apply the same way.
> >I don't think it's unreasonable to require people to predeclare
> >their usage of array-of-compostite-type.
> >
> >Perhaps change the word "CREATE" to "DECLARE". I'm thinking of the
> >explicit declaration of shell types as precedent here.
> >
> #2 would be fine with me - not keen on #1.
Per your earlier suggestion in IRC, I'm picturing a polymorphic
function like
pg_catalog.array_for(typepoid OID)
pg_catalog.array_for(typename NAME)
pg_catalog.array_for(typenamespace NAME, typename NAME)
I don't see a good reason to allow putting array types in a different
schema from their base types.
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter
Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate