Horton

Thread

Commits

  1. Mark built-in coercion functions as leakproof where possible.

  1. Mark unconditionally-safe implicit coercions as leakproof

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-07-24T16:17:11Z

    I went through the system's built-in implicit coercions to see
which ones are unconditionally successful.  These could all be
marked leakproof, as per attached patch.  This came up in the
context of the nearby discussion about CASE, but it seems like
an independent improvement.  If you have a function f(int8)
that is leakproof, you don't want it to effectively become
non-leakproof when you apply it to an int4 or int2 column.

One that I didn't mark leakproof is rtrim1(), which is the
infrastructure for char(n) to text coercion.  It looks like it
actually does qualify right now, but the code is long enough and
complex enough that I think such a marking would be a bit unsafe.

Any objections?

			regards, tom lane

  2. Re: Mark unconditionally-safe implicit coercions as leakproof

    Robert Haas <robertmhaas@gmail.com> — 2020-07-24T16:32:09Z

    On Fri, Jul 24, 2020 at 12:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I went through the system's built-in implicit coercions to see
> which ones are unconditionally successful.  These could all be
> marked leakproof, as per attached patch.  This came up in the
> context of the nearby discussion about CASE, but it seems like
> an independent improvement.  If you have a function f(int8)
> that is leakproof, you don't want it to effectively become
> non-leakproof when you apply it to an int4 or int2 column.
>
> One that I didn't mark leakproof is rtrim1(), which is the
> infrastructure for char(n) to text coercion.  It looks like it
> actually does qualify right now, but the code is long enough and
> complex enough that I think such a marking would be a bit unsafe.
>
> Any objections?

IMHO, this is a nice improvement.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

  3. Re: Mark unconditionally-safe implicit coercions as leakproof

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-07-25T16:57:50Z

    Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 24, 2020 at 12:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I went through the system's built-in implicit coercions to see
>> which ones are unconditionally successful.  These could all be
>> marked leakproof, as per attached patch.

> IMHO, this is a nice improvement.

Thanks; pushed.  On second reading I found that there are a few
non-implicit coercions that could usefully be marked leakproof
as well --- notably float4_numeric and float8_numeric, which should
be error-free now that infinities can be converted.

			regards, tom lane