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

Search Discussions

  • Tom Lane at Mar 2, 2006 at 5:53 am

    Michael Fuhr 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
  • Michael Fuhr at Mar 2, 2006 at 7:42 pm

    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
  • Tom Lane at Mar 2, 2006 at 7:49 pm

    Michael Fuhr 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
  • Michael Fuhr at Mar 2, 2006 at 9:19 pm

    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
  • Bruce Momjian at Mar 6, 2006 at 5:06 am
    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. +
  • Michael Fuhr at Mar 6, 2006 at 7:07 am

    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
  • Jim C. Nasby at Mar 7, 2006 at 4:06 pm

    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
  • Tom Lane at Mar 7, 2006 at 4:12 pm

    "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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 1, '06 at 3:19a
activeMar 7, '06 at 4:12p
posts9
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase