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

From: Robert Haas <[email-masked]>
Date: Fri, 2 Aug 2024 13:39:50 -0400

On Fri, Aug 2, 2024 at 12:33 PM Jacob Champion
<[email-masked]> wrote:
> (Now, if there aren't that many cases where we can all agree on
> "unsafe", then the proposal loses pretty much all value, because we'll
> never shrink the uncertainty.)

My belief is that nearly everything in unsafe. We ship with very
little marked leakproof right now, and that might be too conservative,
but probably not by much. For example:

-- +(int4, int4) is not leakproof
robert.haas=# select 2147483647::int4+1;
ERROR:  integer out of range

-- textcat is not leakproof
robert.haas=# create temp table x as select repeat('a',(2^29)::int4-2)::text a;
SELECT 1
robert.haas=# select length(a||a) from x;
ERROR:  invalid memory alloc request size 1073741824

-- absolute value is not leakproof
robert.haas=# select @(-2147483648);
ERROR:  integer out of range

-- textlike is not leakproof
robert.haas=# select 'a' ~ 'b\';
ERROR:  invalid regular expression: invalid escape \ sequence

-- division is not leakproof
robert.haas=# select 2/0;
ERROR:  division by zero

-- to_date is not leakproof
robert.haas=# select to_date('abc', 'def');
ERROR:  invalid value "a" for "d"
DETAIL:  Value must be an integer.

I think it would be safe to mark the bitwise xor operator for integers
as leakproof. But that isn't likely to be used in a query. Most of the
stuff that people actually use in queries isn't even arguably
leakproof.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

---

From: Jacob Champion <[email-masked]>
Date: Fri, 2 Aug 2024 11:18:16 -0700

On Fri, Aug 2, 2024 at 10:40 AM Robert Haas <[email-masked]> wrote:
> but probably not by much.

Then to me, that seems like the best-case scenario for a "maybe"
classification. I'm still not sold on the idea of automatically
treating all "maybes" as leakproof (personally I'd prefer that users
surgically opt in), but if the pool is small...

Thanks,
--Jacob