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

On 2024-07-31 We 9:14 AM, Joe Conway wrote:
> 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@dunslane.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.
>
--
Andrew Dunstan
EDB: https://www.enterprisedb.com