Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas <heikki.linnakan...@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 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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
