Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS
Дата
Msg-id 350671.1620579698@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
Julien Rouhaud <rjuju123@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 ;-).
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Identify LWLocks in tracepoints