Re: [PATCHES] Non-transactional pg_class, try 2
От | Zeugswetter Andreas DCP SD |
---|---|
Тема | Re: [PATCHES] Non-transactional pg_class, try 2 |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA579011F00E1@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] Non-transactional pg_class, try 2 (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [PATCHES] Non-transactional pg_class, try 2
|
Список | pgsql-hackers |
> > > Suggest that we prevent write operations on Frozen tables by > > > revoking > > all INSERT, UPDATE or DELETE rights held, then enforcing a check > > during GRANT to prevent them being re-enabled. Superusers would need > > to check every time. If we dont do this, then we will have two > > contradictory states marked in the catalog - privilges saying Yes and > > freezing saying No. > > > > No, I'd not mess with the permissions and return a different error > > when trying to modify a frozen table. (It would also be complicated to > > unfreeze after create database) We should make it clear, that freezing > > is no replacement for revoke. > > That was with a mind to performance. Checking every INSERT, > UPDATE and DELETE statement to see if they are being done > against a frozen table seems like a waste. I'd think we would have relminxid in the relcache, so I don't buy the performance argument :-) (You could still do the actual check in the same place where the permission is checked) > There would still be a specific error message for frozen > tables, just on the GRANT rather than the actual DML statements. I'd still prefer to see the error on modify. Those that don't can revoke. Andreas
В списке pgsql-hackers по дате отправления: