Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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 FOR UPDATE/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(at)kaigai(dot)gr(dot)jp>