cascading column drop to index predicates

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

The thing is, if you drop a column that is used in a normal index, yes
the index is now useless - drop it.
However, since you can have (and I have) indexes like this:
CREATE INDEX asdf ON table (a, b, c) WHERE d IS NOT NULL;
If I drop column d, there is no way I want that index to just disappear!

Uh, why not? I don't quite see the argument why d stands in a different
relationship to this index than a,b,c do. The index is equally
meaningless without any of them.

Can we change it to requiring a CASCADE?

It'd likely be a simple code change, but first let's have the argument
why it's a good idea.

regards, tom lane

Tom Lane wrote:

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

The thing is, if you drop a column that is used in a normal index, yes
the index is now useless - drop it.
However, since you can have (and I have) indexes like this:
CREATE INDEX asdf ON table (a, b, c) WHERE d IS NOT NULL;
If I drop column d, there is no way I want that index to just disappear!

Uh, why not? I don't quite see the argument why d stands in a different
relationship to this index than a,b,c do. The index is equally
meaningless without any of them.

Can we change it to requiring a CASCADE?

It'd likely be a simple code change, but first let's have the argument
why it's a good idea.

In that sample mentioned the index might be used mostly with a,b
columns. Dropping the index silently might damage the application
because it relies on an (a,b) index to be present. IMHO only Indexes
that span that single column should be dropped without CASCADE.

Regards,
Andreas

Andreas Pflug <pgadmin@pse-consulting.de> writes:

In that sample mentioned the index might be used mostly with a,b
columns. Dropping the index silently might damage the application
because it relies on an (a,b) index to be present. IMHO only Indexes
that span that single column should be dropped without CASCADE.

That argument makes no sense to me at all. If you drop the *column*
a or b, and do not thereby break your application, how is the
disappearance of the index on it going to break anything? The index
is meaningless without something to index.

I think the question at hand is whether the same logic applies to
partial indexes: if the index's condition is no longer meaningful, is
the index meaningful? I think we can handle both cases the same way.
But clearly an index condition isn't quite the same thing as an index
column, so maybe someone can make a good argument for treating them
differently.

regards, tom lane

On Mon, 2003-12-22 at 10:55, Tom Lane wrote:

Andreas Pflug <pgadmin@pse-consulting.de> writes:

In that sample mentioned the index might be used mostly with a,b
columns. Dropping the index silently might damage the application
because it relies on an (a,b) index to be present. IMHO only Indexes
that span that single column should be dropped without CASCADE.

That argument makes no sense to me at all. If you drop the *column*
a or b, and do not thereby break your application, how is the
disappearance of the index on it going to break anything? The index
is meaningless without something to index.

I think Andreas is trying to argue that if you drop column b from index
(a, b) that the index should be converted into index(a) -- assuming of
course there isn't already an index(a).

Rod Taylor <pg@rbt.ca> writes:

I think Andreas is trying to argue that if you drop column b from index
(a, b) that the index should be converted into index(a) -- assuming of
course there isn't already an index(a).

That seems to be well outside the charter of DROP CASCADE. I think we
either drop or don't drop; we don't go building new indexes, which is
what this would take. There are also definitional problems --- for
instance, if the index is UNIQUE, does it transmogrify into a UNIQUE
constraint on A alone (which would most likely fail)?

regards, tom lane

Tom Lane wrote:

Rod Taylor <pg@rbt.ca> writes:

I think Andreas is trying to argue that if you drop column b from index
(a, b) that the index should be converted into index(a) -- assuming of
course there isn't already an index(a).

That seems to be well outside the charter of DROP CASCADE. I think we
either drop or don't drop; we don't go building new indexes, which is
what this would take. There are also definitional problems --- for
instance, if the index is UNIQUE, does it transmogrify into a UNIQUE
constraint on A alone (which would most likely fail)?

Agreed, auto creation wouldn't be necessary/expected. If you drop,
objects disappear, you don't expect them to morph. But I'd like to be
inhibited to drop the column if it requires a somewhat recreated index
on (a). So IMHO a DROP INDEX [RESTRICT] should drop only dependent
objects if this won't affect others.

Regards,
Andreas

This is a preliminary patch - don't commit it.

What this patch adds are the CATALOG and NOCATALOG clauses to the CREATE
USER and ALTER USER commands.

These clauses affect the usecatupd column. This makes it easy to create
superusers who cannot manually modify columns (a very nasty power...)

These days, Postgres's built-in command set can do everything you need to
to (except disable triggers and delete all the users...), so I don't see
why people who have the power to create users should also have the power
to munge your entire db server.

There are a few problems that need thinking about, and I would like
comments on how to address them:

1. Should we only allow users who currently hold the catalog perm to grant
it to others? I think yes, since otherwise a regular superuser can create
themselves another account with the catalog priv.

2. Restoring a dump (or dumpall more specifically perhaps) now requires
that the restoring user is more than just a superuser, they must also hold
the catalog priv. This is why:

DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database
WHERE datname = 'template0');

And also this:

-X disable-triggers

3. Upgrading from previous postgres will not give their old superusers
back their catalog privilege, unless they dump with 7.5's pg_dump.

Comments?

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

1. Should we only allow users who currently hold the catalog perm to grant
it to others? I think yes, since otherwise a regular superuser can create
themselves another account with the catalog priv.

That brings up the whole business of just how super is a superuser,
and does it even make sense to try to design a "not quite superuser"
protection state. I'm not convinced that the usecatupd flag is so well
thought out that we should expose it for general use without some
consideration of alternative designs.

As an example, it might make more sense to create a separate flag bit
that simply grants the ability to add and delete users (non-superusers,
presumably), with none of the other attributes of a superuser. If I
recall your original concern properly, this would be a safer facility
for what you wanted to accomplish.

3. Upgrading from previous postgres will not give their old superusers
back their catalog privilege, unless they dump with 7.5's pg_dump.

Only if you make it default to NOCATALOG, which is highly debatable in
my mind, since it is non-backwards-compatible.

regards, tom lane

Tom Lane wrote:

As an example, it might make more sense to create a separate flag bit
that simply grants the ability to add and delete users
(non-superusers, presumably), with none of the other attributes of a
superuser. If I recall your original concern properly, this would be
a safer facility for what you wanted to accomplish.

I agree, this would be a more useful way to slice it up. Or maybe
someone wants to implement the SQL equivalent of "sudo".