Re: can we mark upper/lower/textlike functions leakproof?

On 7/31/24 05:47, Andrew Dunstan wrote:
> On 2024-07-30 Tu 6:51 PM, David Rowley wrote:
>> On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>>> Fast forward to now. The customer has found no observable ill effects of
>>> marking these functions leakproof. The would like to know if there is
>>> any reason why we can't mark them leakproof, so that they don't have to
>>> do this in every database of every cluster they use.
>>>
>>> Thoughts?
>> According to [1], it's just not been done yet due to concerns about
>> risk to reward ratios. Nobody mentioned any reason why it couldn't
>> be, but there were some fears that future code changes could yield new
>> failure paths.
>>
>> David
>>
>> [1]https://postgr.es/m/02BDFCCF-BDBB-4658-9717-4D95F9A91561%40thebuild.com
>
> Hmm, somehow I missed that thread in searching, and clearly I'd
> forgotten it.
>
> Still, I'm not terribly convinced by arguments along the lines you're
> suggesting. "Sufficient unto the day is the evil thereof." Maybe we need
> a test to make sure we don't make changes along those lines, although I
> have no idea what such a test would look like.

I think I have expressed this opinion before (which was shot down), and
I will grant that it is hand-wavy, but I will give it another try.

In my opinion, for this use case and others, it should be possible to
redact the values substituted into log messages based on some criteria.
One of those criteria could be "I am in a leakproof call right now". In
fact in a similar fashion, an extension ought to be able to mutate the
log message based on the entire string, e.g. when "ALTER
ROLE...PASSWORD..." is spotted I would like to be able to redact
everything after "PASSWORD".

Yes it might render the error message unhelpful, but I know of users
that would accept that tradeoff in order to get better performance and
security on their production workloads. Or in some cases (e.g. PASSWORD)
just better security.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com