Re: Only owners can ANALYZE tables...seems overly restrictive

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Only owners can ANALYZE tables...seems overly restrictive
Дата
Msg-id CAKFQuwZM34CXc+m8O=bKMdx4aXStSP8MLhgzHh3w-oVdAB5S1g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Only owners can ANALYZE tables...seems overly restrictive  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: Only owners can ANALYZE tables...seems overly restrictive  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
On Mon, Feb 29, 2016 at 10:35 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
On 02/29/2016 09:09 AM, David G. Johnston wrote:

Being able to run ANALYZE on a table in no way implies that ​I should be
allowed to run ALTER TABLE SET STATISTICS on the same.


Only table owners should be allowed to execute ALTER TABLE while, in my
opinion, anyone with write capabilities on a table should be allowed to
execute ANALYZE.​  I would accept a GRANT permission if that could get
committed but I find the status-quo mildly annoying.

I think a better question at this point is: What is the problem you are trying to solve? Think about the following:

1. When you run ANALYZE it will update the statistics.
2. Anyone can run SET, which means that if any user can run ANALYZE, any user can greatly modify the statistics.

​OK - so the true problem has been identified.​

3. This can already be handled by GRANT:

* psql -U jd -h localhost;
* create table foo (id text);
* create role jd_role;
* alter table foo owner to jd_role;
* grant jd_role to boo;
* \c jd boo
* analyze foo;

​I dislike the fact that this solution involves giving someone who only cares about DML the capability to also perform DDL.

Given these two things it seems the least difficult solution that doesn't make things any worse is to make "ANALYZE" grantable.  If you were going to give the user owner permissions anyway then having a less-inclusive permission cannot hurt.

​The whole allowing session-local statistic targets seems suspect but I suppose it could be useful for development.​  I don't imagine it being very helpful in production since the autovacuum process is eventually just going to reset them back using the server default target at some point.  Maybe for temporary tables which themselves are session-local.

David J.

В списке pgsql-general по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: multicolumn index and setting effective_cache_size using human-readable-numbers
Следующее
От: Peter Devoy
Дата:
Сообщение: Re: bloated postgres data folder, clean up