From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, David Fetter <david(at)fetter(dot)org>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: updated WIP: arrays of composites |
Date: | 2007-05-11 21:21:13 |
Message-ID: | 4644DE49.7050703@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
>
> There is *tons* of legacy code that uses _foo, mainly because there was
> a time when we didn't support the [] notation in a lot of places where
> types can be named. There still are some places, in fact:
>
> regression=# alter type widget[] set schema public;
> ERROR: syntax error at or near "["
> LINE 1: alter type widget[] set schema public;
> ^
> regression=# alter type _widget set schema public;
> ERROR: cannot alter array type widget[]
> HINT: You can alter type widget, which will alter the array type as well.
> regression=#
>
> That particular one may not need fixed (anymore) but the real problem is
> the torches-and-pitchforks session that will ensue if we break legacy
> code for no reason beyond cosmetics.
>
> IIRC some of the contrib modules still have instances of _foo in
> their SQL scripts.
>
Then I think we need to work out a way to make pg_dump smart enough to
dump things in the right order.
Can we perhaps explicitly deprecate using the type name to refer to
array types?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-11 21:37:04 | Re: updated WIP: arrays of composites |
Previous Message | Tom Lane | 2007-05-11 20:45:58 | Re: updated WIP: arrays of composites |