| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Flexible permissions for REFRESH MATERIALIZED VIEW |
| Date: | 2018-05-19 14:06:02 |
| Message-ID: | CA+Tgmoa7_cC5fwCSsCMnxPxCyH5FOTMpQ9c0xbDCnySWtTRodQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 18, 2018 at 8:13 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I'm not a big fan of it- what happens when we introduce something else
> which would seem like it'd fall under 'maintain' but provides some
> capability that maybe it wouldn't be good for users who could only run
> the above commands to have? I'm tempted to suggest that, really, we
> might even be thinking about splitting up things further than the above
> proposal- what about VACUUM vs. VACUUM FULL? Or REFRESH MATVIEW vs.
> REFRESH MATVIEW CONCURRENTLY? Mistakes between those routinly cause
> problems due to the heavy lock taken in some cases- as an administrator,
> I'd be a lot more comfortable giving a user or some process the ability
> to run a VACUUM vs. VACUUM FULL.
That is a fair point, but if we want to do things like that then it's
really not a good idea to limit ourselves to a fixed number of bits,
even if it's 2x or 4x more than what we have today.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2018-05-19 16:59:44 | Re: Flexible permissions for REFRESH MATERIALIZED VIEW |
| Previous Message | Michael Paquier | 2018-05-19 12:35:57 | Re: SCRAM with channel binding downgrade attack |