On Fri, Aug 2, 2024 at 12:33 PM Jacob Champion
<jacob.champ...@enterprisedb.com> 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
