Joe Conway [EMAIL PROTECTED] writes:
Why wouldn't we force checkAsUser to the rule owner in the copied RTEs,
similar to the rest of the rule query?
Because it would be the wrong check. We need to check that the rule
caller has permissions on the view for whatever he originally tried
to do
Tom Lane wrote:
No; it's possible for the amalgamated query to include references to
tables that are referenced only in the original query and nowhere in the
text of the rule. (This is obviously possible right now, since we just
take the union of the two rtables and don't make any effort to
[ please respect moving of thread to pg-hackers ]
Joe Conway [EMAIL PROTECTED] writes:
ISTM that we want the relations in the un-rewritten query checked based
on the basis of the user referencing the rule and for the modes used in
the un-rewritten query -- suggesting the change need be
Tom Lane wrote:
Reverting the change will bring back the bug for which it was created.
It does seem though that we have an inadequate model of how to perform
permission checks. In particular, the write flag bit in RTEs is
context dependent: it can mean insert, update, or delete permission
Joe Conway [EMAIL PROTECTED] writes:
Sorry if I'm being thick, but what of this?
This is exactly what I'm talking about. The rtable for a query
generated by a rule is the concatenation of the original query's rtable
and the rule query's rtable. Therefore the RTE for table1 appears
twice, once
Tom Lane wrote:
This is exactly what I'm talking about. The rtable for a query
generated by a rule is the concatenation of the original query's rtable
and the rule query's rtable. Therefore the RTE for table1 appears
twice, once in the original INSERT query and once in the generated
UPDATE query
Joe Conway [EMAIL PROTECTED] writes:
OK, that makes more sense now. But why isn't table2 also in the rule
query's rtable?
It is, but you errored out before getting to it.
regards, tom lane
---(end of broadcast)---
TIP 9:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
OK, that makes more sense now. But why isn't table2 also in the rule
query's rtable?
It is, but you errored out before getting to it.
The fog has finally started lifting, I think.
Why wouldn't we force checkAsUser to the rule owner in the