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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-15 16:00:37
Message-ID: CA+TgmoanzpfAWZDfOipThh-LtCdzROmeE5Z8BFfvy6QFntsKNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 13, 2021 at 4:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The main reason I'm concerned about applying that rule to amvalidate
> is that then how do you know what's actually an error case?
>
> As a hardly-irrelevant counterexample, we have a whole bunch of
> regression tests that do something like
>
> SELECT ...
> WHERE NOT amvalidate(oid);
>
> Every one of those is silently and dangerously wrong if amvalidate
> might sometimes return null.

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.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-05-15 17:30:06 Re: compute_query_id and pg_stat_statements
Previous Message Ranier Vilela 2021-05-15 14:35:13 Re: Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c)