Re: Mark unconditionally-safe implicit coercions as leakproof
От | Robert Haas |
---|---|
Тема | Re: Mark unconditionally-safe implicit coercions as leakproof |
Дата | |
Msg-id | CA+TgmoZVXsyUv74FBedY=jg4+Pp8jNHv_BC3gVfkso8wrJU5ow@mail.gmail.com обсуждение исходный текст |
Ответ на | Mark unconditionally-safe implicit coercions as leakproof (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Mark unconditionally-safe implicit coercions as leakproof
|
Список | 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
В списке pgsql-hackers по дате отправления: