From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS |
Date: | 2021-05-09 17:01:38 |
Message-ID: | 350671.1620579698@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Julien Rouhaud <rjuju123(at)gmail(dot)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 ;-).
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-05-09 18:55:04 | Re: [PATCH] Identify LWLocks in tracepoints |
Previous Message | Andrew Dunstan | 2021-05-09 14:30:06 | Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS |