On 2014-01-31 16:05, Stephen Frost wrote:
* Yeb Havinga (y.t.havi...@mgrid.net) wrote:
IMHO, there is another way to implement this, other than the
procedure to override the child-rel-quals with the ones from the
parent. At DDL time, synchronize quals on the parent with rls quals
of the childs. Isn't this also what happens with constraints?
No, we're not going to do that. We don't do it for GRANT and I don't
think it makes sense to do it here.
This reasoning could go either way. GRANT is on a complete set of rows.
This is a restriction on the level of individual rows, and in that
sense, it is more like a row-level CHECK constraint.
If we wanted to make them the same then we'd throw out the ability to do
any kind of changes or actions on the child and then we'd have actual
partitioning. We don't have that though, we have inheiritance.
I fail to understand this, probably because I do not have a partition
use case for inheritance, but rather an information model that is more
ontology like. The more specific childs get down the inheritance tree,
more columns they get, and their requirements might differ completely in
nature from their siblings, and make no sense at all as well when
specified at the level of the parent (or even impossible, since the
parent does not have all the columns).
Then during expansion of the range table, no code is needed to
ignore child rls quals and copy parent rels to child rels.
This is what's already implemented and isn't a huge amount of code to
begin with, so I don't see this as being an argument against having the
flexibility.
It would seem to me that any additional logic that can be avoided during
planning is a good thing. Also, the argument that something is already
implemented, does not itself make it good to commit.
What do you mean with 'having the flexibility' and why is that good?
Also, the security policy applied would be invariant to the route
through which the rows were accessed:
You could also get this by simply only allowing access to the parent and
not granting any privileges on the children.
That might work for partitioning, but not for use cases where childs
have more columns than parents.
- directly to the child row: child rls quals and parent quals (by
propagate at ddl) are applied.
- through the parent: child rls quals and parent quals applied.
If you want them to be the same then you can implement this yourself
without having PG force it on you.
I suggested it as a solution for a requirement worded upthread as "It
makes absolutely zero sense, in my head anyway, to have rows returned
when querying the parent which should NOT be returned based on the quals
of the parent." without disregarding rls-quals on childs.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
