On Sun, May 09, 2021 at 01:01:38PM -0400, Tom Lane wrote: > Julien Rouhaud <rjuju...@gmail.com> writes: > > Looking at the patch, explicitly_binary_coercible wasn't used since > > e9f42d529f990f94e1b7bdcec4a1111465c85326 (and was renamed there too). Just > > to > > be sure, is it ok to remove it, as it was described as > > >> --- We don't currently use this for any tests in this file, but it is a > >> --- reasonable alternative definition for some scenarios. > > > It would still be in the git history in needed, so I'm not objecting. > > It's my own comment, so it doesn't scare me particularly ;-).
Yes, I saw that when digging in git history :) > I think that > > (a) it's unlikely we'll ever again need that old physically-coercible > check. That was a hangover from Berkeley-era type cheats, and I think > our standards are higher now. If somebody submits a patch that would > depend on such a cheat, I think our response would be "fix the patch", > not "it's okay to weaken the type-matching checks". > > (b) if we did need it, we'd probably want an implementation like this > one (ie invoke some C code), both for speed and because it's hard to > make a plpgsql function's behavior match the C code's exactly. I quite agree with both. As I said I just wanted to mention it for extra safety.
