Re: about truncate
От | Peter Eisentraut |
---|---|
Тема | Re: about truncate |
Дата | |
Msg-id | 4964CEEB.8090305@gmx.net обсуждение исходный текст |
Ответ на | Re: about truncate (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: about truncate
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: about truncate (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: