Tom Lane wrote:
I note though that we have a lot of other non-recursive maintenance
operations (CLUSTER, some variants of ALTER TABLE, etc) ... are we
going to try to make them all recursive?
Here is the current line-up:
command supports ONLY
ALTER TABLE all other actions yes
ALTER TABLE RENAME COLUMN yes
ALTER TABLE RENAME no
ALTER TABLE SET SCHEMA documented no, but accepted and ignored
ANALYZE no
CLUSTER no
COMMENT no
COPY no
CREATE INDEX no
DELETE yes
DROP TABLE no
GRANT no
INSERT no
LOCK no
REINDEX no
REVOKE no
SELECT yes
TRUNCATE no
UPDATE yes
VACUUM no
Obviously, there is no practical sense in making them all behave the
same, because ALTER TABLE RENAME not-ONLY for example would be nonsense.
So there are always going to be two kinds of commands: "logical" ones
that operate try to give the illusion that inheriting tables are
included in the parent table, and "physical" ones that operate on a in
single table only.
About the current situation:
Most people seemed to agree that TRUNCATE should support ONLY, to behave
like DELETE.
ALTER TABLE SET SCHEMA appears to be an omission.
There could be some rare use cases for recursive versions of ANALYZE,
CLUSTER, REINDEX, and VACUUM, but those would only be for convenience
and would have no logical effect.
A recursive version of CREATE INDEX could be quite useful, but that
might belong into the whole inheritance vs. indexes bag of a mess.
LOCK got me thinking. If you have a situation where an explicit lock is
necessary because serializable transaction isolation does not give you
the necessary guarantees, you would really want LOCK to be recursive.
If you happen to write your application properly following one of the
few obscure practical examples about explicit locking, and then the DBA
partitions the table under you, you lose quite badly.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
