Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> That way you could
>>> grant SELECT_FOR_SHARE permission on a table to let people insert rows
>>> into other tables that have a foreign key reference to it, without
>>> having to grant UPDATE permission.
>>
>> ... but this argument for it is utter nonsense.  FKs are not a
>> permissions problem, because the triggers run as the table's owner.
>> The only permission you need is REFERENCES:
> 
> Then I think we should leave it as it is. I don't see any plausible use 
> case for a separate SELECT FOR SHARE or UPDATE permission.

My concern is not on the vanilla PostgreSQL's access controls.

In the discussion for v8.4 development cycle, I got a suggestion that
the query-tree-walker routine is a duplication of the code so we should
utilize the information collected by the core analyzer. I agreed this
design changes and it enabled to simplify the implementation.
However, ACL_UPDATE and ACL_SELECT_FOR_UPDATE internally shares same bit
so SE-PostgreSQL cannot discriminate between UPDATE and SELECT FOR UPDATE
or SHARE. It has been a headach for me.

Last night, I got an another idea without any changes ACL_xxx definitions.
If the given rte->requiredPerms has ACL_UPDATE (or ACL_SELECT_FOR_UPDATE),
we might be able to discriminate them using rte->modifiedCols, because
UPDATE statement set a bit on rte->modifiedCols at least.
  if (rte->requiredPerms & ACL_UPDATE) {      if (bms_is_empty(rte->modifiedCols))          // consider it as SELECT
FORUPDATE/SHARE      else          // consider it as UPDATE  }
 

If we don't have a (internally) separate bit on ACL_SELECT_FOR_UPDATE,
it can be a solution for SE-PostgreSQL.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>