"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Having to change the types to shells, then drop the IO, then drop the
> type seems like a 'gotcha' and a bunch of needless extra work.
Depends. From pg_dump's perspective it's easier to do it that way,
because it drives all this from a reverse-dependen
On Mon, Mar 06, 2006 at 12:07:34AM -0700, Michael Fuhr wrote:
> On Mon, Mar 06, 2006 at 12:06:28AM -0500, Bruce Momjian wrote:
> > Is there any progress on this cleanup?
>
> I'm still planning to work on it unless somebody else wants to, but
> I was hoping for more feedback on the use of DROP TYPE
On Mon, Mar 06, 2006 at 12:06:28AM -0500, Bruce Momjian wrote:
> Is there any progress on this cleanup?
I'm still planning to work on it unless somebody else wants to, but
I was hoping for more feedback on the use of DROP TYPE CASCADE.
That seems to be the only way to remove a type due to the circ
Is there any progress on this cleanup?
---
Michael Fuhr wrote:
> On Thu, Mar 02, 2006 at 02:49:13PM -0500, Tom Lane wrote:
> > Michael Fuhr <[EMAIL PROTECTED]> writes:
> > > Would it make sense for DROP TYPE to have some kin
On Thu, Mar 02, 2006 at 02:49:13PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Would it make sense for DROP TYPE to have some kind of limited
> > cascade so you could drop a type and its I/O functions at the same
> > time, but still get an error if other objects depend on
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Would it make sense for DROP TYPE to have some kind of limited
> cascade so you could drop a type and its I/O functions at the same
> time, but still get an error if other objects depend on the type?
Seems pretty ugly. Maybe the thing to do is have a com
On Thu, Mar 02, 2006 at 12:52:05AM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > ... I started to work on a patch but I wasn't sure how
> > to handle the chicken-and-egg situation of dropping a type and its
> > I/O functions. Is there any way to do that other than DROP TYP
Michael Fuhr <[EMAIL PROTECTED]> writes:
> ... I started to work on a patch but I wasn't sure how
> to handle the chicken-and-egg situation of dropping a type and its
> I/O functions. Is there any way to do that other than DROP TYPE
> CASCADE? Should the uninstall scripts be doing that?
DROP TY
Several of the new uninstall scripts give errors, particularly those
that drop types and their support objects. To see an example:
createdb foo
psql -d foo -f ltree.sql
psql -d foo -f uninstall_ltree.sql
A lot of the errors are due to DROP OPERATOR CLASS lines missing
the required USING clause;
