From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: can we mark upper/lower/textlike functions leakproof? |
Date: | 2024-08-02 16:13:31 |
Message-ID: | 06cc6dcf-37c2-44d6-9232-a82a858be289@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/2/24 11:07, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> <dons flameproof suit>
>> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
>> current behavior, 'lax' allows the 'maybe's to get pushed down, and
>> 'off' ignores the leakproof attribute entirely and pushes down anything
>> that merits being pushed?
>> </dons flameproof suit>
>
> So in other words, we might as well just remove RLS.
Perhaps deciding where to draw the line for 'maybe' is too hard, but I
don't understand how you can say that in a general sense.
'strict' mode would provide the same guarantees as today. And even 'off'
has utility for cases where (1) no logins are allowed except for the app
(which is quite common in production environments) and no database
errors are propagated to the end client (again pretty standard best
practice); or (2) non-production environments, e.g. for testing or
debugging; or (3) use cases that utilize RLS as a notationally
convenient filtering mechanism and are not bothered by some leakage in
the worst case.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2024-08-02 16:15:07 | Re: Memory growth observed with C++ application consuming libpq.dll on Windows |
Previous Message | Alvaro Herrera | 2024-08-02 16:07:30 | Re: wrong translation file reference in pg_createsubscriber |