Re: Uninstall script errors

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; since that line fails so do subsequent
DROP OPERATOR and DROP FUNCTION lines because the operator class
still exists. I've found a few other errors as well, such as a
CREATE TYPE line in uninstall_dblink.sql and a couple of DROP
FUNCTION lines in uninstall_btree_gist.sql for functions that were
never created. 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?

--
Michael Fuhr

Michael Fuhr <mike(at)fuhr(dot)org> 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 TYPE CASCADE is probably reasonable; that's the way pg_dump
handles the problem, anyway.

regards, tom lane

On Thu, Mar 02, 2006 at 12:52:05AM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)org> 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 TYPE CASCADE is probably reasonable; that's the way pg_dump
> handles the problem, anyway.

If the uninstall scripts do DROP TYPE CASCADE then would there be
any reason to keep the drops for support objects? The cascade would
remove everything at a stroke; without the drops for operators,
functions, etc., the scripts would be much simpler.

My concern with DROP TYPE CASCADE is the effect on objects like
tables with a column of that type. Are the uninstall scripts
intended to do forced drops, or does the absence of CASCADE in the
scripts imply that they're meant to fail if dependent objects exist?

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?

--
Michael Fuhr

Michael Fuhr <mike(at)fuhr(dot)org> 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 command that somehow
reverts a type to the "shell" state, whereupon the deletion sequence can
be the exact logical inverse of the creation sequence:

* drop other dependencies
* shell-ify type
* drop I/O functions
* drop shell type

What's not very clear to me though is how you determine whether it's
safe to shell-ify the type. I don't think you want to allow that as
long as any columns of the type remain, for instance. If this requires
verifying that it has no remaining dependencies except the I/O
functions, then it seems no different really from a "limited cascade".

regards, tom lane

On Thu, Mar 02, 2006 at 02:49:13PM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)org> 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 command that somehow
> reverts a type to the "shell" state, whereupon the deletion sequence can
> be the exact logical inverse of the creation sequence:

I thought the same thing after the recent commits involving shell
types and got similarly stuck.

Do people at least agree that a DROP TYPE that works without CASCADE
would be desirable? The rationale is the same as for other DROP
commands: drop the object if nothing depends on it, else raise an
error. That's impossible now because of the circular dependency
between a type and its I/O functions, which requires the use of
CASCADE.

--
Michael Fuhr

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 <mike(at)fuhr(dot)org> 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 command that somehow
> > reverts a type to the "shell" state, whereupon the deletion sequence can
> > be the exact logical inverse of the creation sequence:
>
> I thought the same thing after the recent commits involving shell
> types and got similarly stuck.
>
> Do people at least agree that a DROP TYPE that works without CASCADE
> would be desirable? The rationale is the same as for other DROP
> commands: drop the object if nothing depends on it, else raise an
> error. That's impossible now because of the circular dependency
> between a type and its I/O functions, which requires the use of
> CASCADE.
>
> --
> Michael Fuhr
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

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 circular
dependency between the type and its I/O functions, but I'm wary of
CASCADE due to its destructive power. Hence my question about
whether the uninstall scripts are intended to do forced drops or
whether they should fail if dependent objects still exist.

Here are some options I'm thinking about:

1. Use DROP TYPE CASCADE and eliminate the drops for operators,
functions, etc., because the cascade will drop them anyway. This
would make the uninstall scripts simpler than they currently are.

2. Use DROP TYPE CASCADE and keep the drops for support objects.
This would result in the fewest number of changes to the current
scripts.

3. Use DROP TYPE CASCADE, keep the drops for support objects, and
wrap all the drops in a transaction. Certain kinds of dependencies
(e.g., an index dependency on an operator class) will cause one of
those drops to fail, aborting the transaction before it reaches
DROP TYPE CASCADE. This would provide some protection against
dropping a type when dependent objects still exist, but it's not
foolproof. An unindexed column might depend only on the type itself,
so none of the drops would fail and that column would be dropped
by the DROP TYPE CASCADE.

4. Wait for a decision about whether DROP TYPE should be modified
to have the ability to revert the type to a shell so the I/O functions
and finally the type itself can be dropped without using CASCADE.
Another possibility, which Tom has already said is "pretty ugly,"
would be a "limited cascade" whereby DROP TYPE would cascade to the
I/O functions but would raise an error if other dependent objects
still exist.

Comments? Other possibilities?

--
Michael Fuhr

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 CASCADE.
> That seems to be the only way to remove a type due to the circular
> dependency between the type and its I/O functions, but I'm wary of
> CASCADE due to its destructive power. Hence my question about
> whether the uninstall scripts are intended to do forced drops or
> whether they should fail if dependent objects still exist.
>
> Here are some options I'm thinking about:
>
> 1. Use DROP TYPE CASCADE and eliminate the drops for operators,
> functions, etc., because the cascade will drop them anyway. This
> would make the uninstall scripts simpler than they currently are.
>
> 2. Use DROP TYPE CASCADE and keep the drops for support objects.
> This would result in the fewest number of changes to the current
> scripts.
>
> 3. Use DROP TYPE CASCADE, keep the drops for support objects, and
> wrap all the drops in a transaction. Certain kinds of dependencies
> (e.g., an index dependency on an operator class) will cause one of
> those drops to fail, aborting the transaction before it reaches
> DROP TYPE CASCADE. This would provide some protection against
> dropping a type when dependent objects still exist, but it's not
> foolproof. An unindexed column might depend only on the type itself,
> so none of the drops would fail and that column would be dropped
> by the DROP TYPE CASCADE.
>
> 4. Wait for a decision about whether DROP TYPE should be modified
> to have the ability to revert the type to a shell so the I/O functions
> and finally the type itself can be dropped without using CASCADE.
> Another possibility, which Tom has already said is "pretty ugly,"
> would be a "limited cascade" whereby DROP TYPE would cascade to the
> I/O functions but would raise an error if other dependent objects
> still exist.

TBH, I like Tom's idea in conjunction with a 'more destructive' CASCADE.
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.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> 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-dependency-order traversal
of the objects. If dropping the type magically makes the functions
go away then you'd want to somehow suppress the DROP commands for the
functions, and it's not clear how to do that, or what unpleasant
side-effects it might have (I can think of at least one place in
pg_restore that assumes all ownable objects have DROP commands in a
dump ...)

regards, tom lane