Re: [GENERAL] column-level update privs + lock table
От | Robert Haas |
---|---|
Тема | Re: [GENERAL] column-level update privs + lock table |
Дата | |
Msg-id | AANLkTi=0_m2x0FXLGOMO-SVYw-mBLwMzTXyUfgpt-bw5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] column-level update privs + lock table (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: [GENERAL] column-level update privs + lock table
|
Список | pgsql-hackers |
2010/11/28 KaiGai Kohei <kaigai@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 privileges are enough to do >> this, but this change would allow people to block access to data they >> can neither see nor modify. That seems counterintuitive, if not a >> security hole. >> > In my understanding, UPDATE privilege on a single column also allows > lock out concurrent updating even if this query tries to update rows > partially. > Therefore, the current code considers UPDATE privilege on a single > column is enough to lock out the table. Right? Against concurrent updates and deletes, yes. Against inserts that don't involve potential unique-index conflicts, and against selects, no. > 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 should fix. I don't understand what you're getting at here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: