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
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 |