| From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: RLS without leakproof restrictions? |
| Date: | 2023-02-22 04:12:52 |
| Message-ID: | CAPPfruxgVOfb5FggGKYJB+dY0=pHuUOOjpR8MYR9zzbHj7uW7g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi Tom!
On Wed, 22 Feb 2023 at 14:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If you're happy allowing the application to decide if the filters will
> be enforced, maybe just create some views embodying those filters, and
> query those views when you want restrictions?
>
Yeah, thanks very much for the suggestion. It's more maintenance than RLS
policies as we'll need to update views as tables are modified, and we'll
need to ensure that the app never selects from the underlying table, but it
still beats needing to add filter clauses across the codebase.
Thanks
Tom
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neethu P | 2023-02-22 07:57:21 | Event Triggers unable to capture the DDL script executed |
| Previous Message | Tom Lane | 2023-02-22 03:46:05 | Re: RLS without leakproof restrictions? |