Re: lower() and unaccent() not leakproof

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: lower() and unaccent() not leakproof
Date: 2021-08-26 19:43:10
Message-ID: 673096.1630006990@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> I think the complexity of the implementation of upper() and lower() is
> on the same order as bttextcmp() and similar, so it wouldn't be totally
> out of scope.

True. But you'll recall that the decision to mark bttextcmp() and
cohorts as leakproof was not made without fear. IMV, that decision
did not rest simply on code review but on two arguments about why
we should take the risk:

* The query-optimization usefulness of having those be leakproof
is extremely high.

* btree comparison functions should really not have any user-reachable
failure modes (which comes close to being the definition of leakproof).
If one did, that would mean there were legal values of the type that
couldn't be put into a btree index.

Maybe similar arguments can be made about upper/lower, but I think
it's a far weaker case. As for unaccent, the fact that it relies
on user-controllable definitions seems to me to make it almost
certainly unsafe to be leakproof.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ninad Shah 2021-08-27 06:36:07 Re: Manual failover cluster
Previous Message hubert depesz lubaczewski 2021-08-26 16:06:44 Re: Can we get rid of repeated queries from pg_dump?