Re: Mark unconditionally-safe implicit coercions as leakproof
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-24T16:32:09Z
Lists: pgsql-hackers
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
Commits
-
Mark built-in coercion functions as leakproof where possible.
- 8a37951eebff 14.0 landed