RLS without leakproof restrictions?

From: Tom Dunstan <pgsql(at)tomd(dot)cc>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: RLS without leakproof restrictions?
Date: 2023-02-22 00:57:13
Message-ID: CAPPfruzMB1RQ0LMjHQe=MT1KhDHzaT_gduaMa20dbxC8f6B7og@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi all

I'm currently researching different strategies for retrofitting some
multi-tenant functionality into our existing Postgres-backed application.
One of the options is using RLS policies to do row filtering. This is quite
attractive as I dread the maintenance and auditing burden of adding
filtering clauses to the majority of our queries. I'm somewhat concerned
though about getting unexpected query plans based on the planner avoiding
non-leakproof functions until row filtering has occurred - warning about
this seems common in articles on RLS.

Our application is the only "user" of the database, and we do not pass
database errors through to the user interface, so for our case leakproof
plans are overkill - we'd just like the implicit filtering clauses added
based on some session GUCs that we set.

Is there any way to get what we're looking for here? I don't see anything
documented on CREATE POLICY, ALTER TABLE or any GUCs.

Alternatively, are the concerns about changed plans unfounded? For example
we don't use many expression indexes or exotic types, it's mostly btrees on
text and ints. We do use tsearch a certain amount, but constructing
tsvectors and tsqueries manually rather than through stemmers etc.

Thanks

Tom

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Cathy Xie 2023-02-22 01:18:12 Re: Debugging postgres on Windows - could not open directory "/lib"
Previous Message Bryn Llewellyn 2023-02-22 00:06:52 Re: transaction_isolation vs. default_transaction_isolation