Mark unconditionally-safe implicit coercions as leakproof
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
Attachments:
mark-safe-coercions-as-leakproof-1.patchtext/x-diff; charset=us-ascii; name=mark-safe-coercions-as-leakproof-1.patchDownload+40-20
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
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