On Tue, Nov 30, 2010 at 1:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the whole I agree with Robert --- let's just adjust the
documentation, and not enlarge privileges in a way we might regret
later.
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Mon, Nov 29, 2010 at 10:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt schmi...@gmail.com wrote:
I actually hadn't thought of that, for some reason.
We used to similarly recommend that people handle TRUNCATE privileges
with a security
On Tue, Nov 30, 2010 at 9:07 AM, Josh Kupershmidt schmi...@gmail.com wrote:
On Mon, Nov 29, 2010 at 10:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt schmi...@gmail.com wrote:
I actually hadn't thought of that, for some reason.
We used to
On Mon, 2010-11-29 at 21:37 -0500, Josh Kupershmidt wrote:
I still see little reason to make LOCK TABLE permissions different for
column-level vs. table-level UPDATE privileges
Agreed.
This is the crux of the debate. Why should this inconsistency be allowed
to continue?
Are there covert
On Tue, Nov 30, 2010 at 7:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-11-29 at 21:37 -0500, Josh Kupershmidt wrote:
I still see little reason to make LOCK TABLE permissions different for
column-level vs. table-level UPDATE privileges
Agreed.
This is the crux of the debate.
Robert Haas robertmh...@gmail.com writes:
Well, a user with full-table UPDATE privileges can trash the whole
thing, so, from a security perspective, letting them lock is only
allowing them to deny access to data they could have just as easily
trashed. A user with only single-column UPDATE
(2010/11/30 21:26), Simon Riggs wrote:
On Mon, 2010-11-29 at 21:37 -0500, Josh Kupershmidt wrote:
I still see little reason to make LOCK TABLE permissions different for
column-level vs. table-level UPDATE privileges
Agreed.
This is the crux of the debate. Why should this inconsistency
2010/11/28 KaiGai Kohei kai...@ak.jp.nec.com:
My comment was from a standpoint which wants consistent behavior
between SELECT ... FOR and LOCK command.
Again, nothing about this makes those consistent.
If we concerned about this
behavior, ExecCheckRTEPerms() might be a place where we also
On Mon, Nov 29, 2010 at 10:50 AM, Robert Haas robertmh...@gmail.com wrote:
A user with single-column UPDATE privileges could obtain a ROW
EXCLUSIVE lock by issuing an UPDATE statement, but currently cannot
obtain the same lock using LOCK TABLE. It would be reasonable and
consistent to allow
On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt schmi...@gmail.com wrote:
It seems to me that if we're really worried about which locks users
are allowed to take (and so far all of the worrying seems to lack a
solid basis in any sort of usability argument) we'd need to invent
some
On Fri, Nov 26, 2010 at 7:11 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not totally convinced that this is the correct behavior. It seems
a bit surprising that UPDATE privilege on a single column is enough to
lock out all SELECT activity from the table. It's actually a bit
surprising
On Fri, 2010-11-26 at 19:11 -0500, Robert Haas wrote:
2010/11/25 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/10/16 4:49), Josh Kupershmidt wrote:
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggssi...@2ndquadrant.com wrote:
On Mon, 2010-10-11 at 09:41 -0400, Josh
On Sun, Nov 28, 2010 at 11:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-11-26 at 19:11 -0500, Robert Haas wrote:
2010/11/25 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/10/16 4:49), Josh Kupershmidt wrote:
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon
(2010/11/27 9:11), Robert Haas wrote:
2010/11/25 KaiGai Koheikai...@ak.jp.nec.com:
(2010/10/16 4:49), Josh Kupershmidt wrote:
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggssi...@2ndquadrant.com
wrote:
On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
On Thu,
2010/11/28 KaiGai Kohei kai...@ak.jp.nec.com:
I'm not totally convinced that this is the correct behavior. It seems
a bit surprising that UPDATE privilege on a single column is enough to
lock out all SELECT activity from the table. It's actually a bit
surprising that even full-table UPDATE
(2010/11/29 10:43), Robert Haas wrote:
2010/11/28 KaiGai Koheikai...@ak.jp.nec.com:
I'm not totally convinced that this is the correct behavior. It seems
a bit surprising that UPDATE privilege on a single column is enough to
lock out all SELECT activity from the table. It's actually a bit
2010/11/25 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/10/16 4:49), Josh Kupershmidt wrote:
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggssi...@2ndquadrant.com wrote:
On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
On Thu, Oct 7, 2010 at 7:43 PM, Josh
(2010/10/16 4:49), Josh Kupershmidt wrote:
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggssi...@2ndquadrant.com wrote:
On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidtschmi...@gmail.com wrote:
I noticed that
On Fri, Oct 15, 2010 at 3:49 PM, Josh Kupershmidt schmi...@gmail.com wrote:
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt
On Mon, Oct 18, 2010 at 10:27 AM, Robert Haas robertmh...@gmail.com wrote:
Please add this to
https://commitfest.postgresql.org/action/commitfest_view/open
I want to look at this at some point, but we still have over a dozen
patches from the current CF to deal with.
Added at
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt schmi...@gmail.com wrote:
I noticed that granting a user column-level update privileges
21 matches
Mail list logo
