| 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 14:00:01 |
| Message-ID: | 648381.1629986401@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:
> On 26.08.21 06:52, David G. Johnston wrote:
>> On Wednesday, August 25, 2021, Christophe Pettus <xof(at)thebuild(dot)com
>> <mailto:xof(at)thebuild(dot)com>> wrote:
>>> lower() and unaccent() (and most string functions) are not marked as
>>> leakproof. Is this due to possible locale / character encoding
>>> errors they might encounter?
> I think if you trace the code, you might find that lower() and upper()
> can't really leak anything. It might be worth taking a careful look and
> possibly lifting this restriction.
Generally speaking, we've been resistant to marking anything leakproof
unless it has a very small code footprint that can be easily audited.
In particular, anything that shares a lot of infrastructure with
not-leakproof functions seems quite hazardous. Even if you go through
the code and convince yourself that it's OK today, innocent changes
to the shared infrastructure could break the leakproofness tomorrow.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-08-26 14:02:07 | Re: Can we get rid of repeated queries from pg_dump? |
| Previous Message | hubert depesz lubaczewski | 2021-08-26 08:44:30 | Can we get rid of repeated queries from pg_dump? |