On 2019-09-16 06:24, Tom Lane wrote:
> So it seems that the consensus is that it's okay to mark these
> functions leakproof, because if any of the errors they throw
> are truly reachable for other than data-corruption reasons,
> we would wish to try to prevent such errors. (Maybe through
> upstream validity checks? Hard to say how we'd do it exactly,
> when we don't have an idea what the problem is.)
Yeah, it seems like as we expand our Unicode capabilities, we will see
more cases like "it could fail here in theory, but it shouldn't happen
for normal data", and the answer can't be to call all that untrusted or
leaky. It's the job of the database software to sort that out.
Obviously, it will require careful evaluation in each case.
> My inclination is to do the proleakproof changes in HEAD, but
> not touch v12. The inconsistency in leakproof markings in v12
> is annoying but it's not a regression or security hazard, so
> I'm thinking it's not worth a late catversion bump to fix.
Sounds good, unless we do another catversion bump.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services