Thread: 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@fuhr.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@fuhr.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@fuhr.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@fuhr.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@fuhr.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@pervasive.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@pervasive.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