Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS
Date
Msg-id 20210510051413.xbktusae7ttc4jlh@nol
Whole thread Raw
In response to Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, May 09, 2021 at 01:01:38PM -0400, Tom Lane wrote:
> 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 ;-).

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.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions