'Flexible "partition pruning" hook' redux? - Mailing list pgsql-hackers

From Ted Toth
Subject 'Flexible "partition pruning" hook' redux?
Date
Msg-id CAFPpqQE5c9Tsq9km3LMpeX1R4nZ5miEJWonV6FoQTH0nRdKUUw@mail.gmail.com
Whole thread Raw
List pgsql-hackers
There's an old thread that interests me but which ended without any
resolution/solution:

https://www.postgresql.org/messageid/CA%2BHiwqGpoKmDg%2BTJdMfoeu3k4VQnxcfBon4fwBRp8ex_CTCsnA%40mail.gmail.com

Some of our basic requirements are:
1) All data must be labeled at a specific level (using SELinux multi-level
security (MLS) policy).
2) Data of different levels cannot be stored in the same file on disk.
3) The Bell-LaPadula model must be applied meaning read (select) down (return
rows labeled at levels dominated by the querying processes level) is allowed,
updates (insert/update/delete) can only be done to data at the same level as
executing process. BLM allows for write up but in reality since processes don't
know about levels which dominate theirs this doesn't happen.

In the past I've used RLS, sepgsql and some additional custom functions to
create MLS databases but this does not satisfy #2. Partitioning looks to be a
way to achieve #2 and to possibly improve query performance since partitions
could be pruned based on the level of data stored in them. However I'm not
aware of a means to implement table level dominance pruning. The patch,
in the thread noted above, proposed a hook to allow customized pruning of
partitions which is something I think would be useful. However a number of
questions and concerns were raised (some beyond my ability to even comprehend since I don't have intimate knowledge of the code base) but never addressed.
What's the best way forward in a situation like this?

Ted

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Introduce a new view for checkpointer related stats