Re: amvalidate(): cache lookup failed for operator class 123

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: amvalidate(): cache lookup failed for operator class 123
Date: 2021-05-17 04:48:03
Message-ID: YKH1g9bG4V4JmG46@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 15, 2021 at 12:00:37PM -0400, Robert Haas wrote:
> Oh, I didn't notice previously that Justin's proposal was to make the
> functions return NULL. He's correct that this is consistent with other
> cases, and if we go that way, then these queries need to be updated. I
> had just been imaging using ereport(ERROR, ...) which wouldn't have
> that problem. I think either approach would be an improvement over the
> status quo.

FWIW, I am not convinced with what we could gain by sending NULL as
result rather than bump on an ERROR with this function. Don't take me
wrong, I like when system functions return a gentle NULL result if
something does not exist, if the function is something we document and
if it can be used with large catalog scans a-la-pg_class. I don't
think that there is any need to apply that to amvalidate() though, and
it could mean potential issues with out-of-core modules, rum for one,
no?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2021-05-17 04:48:31 Re: Typo in README.barrier
Previous Message Masahiko Sawada 2021-05-17 04:46:37 Re: use AV worker items infrastructure for GIN pending list's cleanup