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-13 20:12:10
Message-ID: CA+Tgmob8RSX3RzZ1uMBKKyMsMEZx0J51Pi213Mko6t8Fm4mMgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 13, 2021 at 2:22 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Meh. I'm not convinced that that position ought to apply to amvalidate.

I am still of the opinion that we ought to apply it across the board,
for consistency. It makes it easier for humans to know which problems
are known to be reachable and which are thought to be can't-happen and
thus bugs. If we fix cases like this to return a real error code, then
anything that comes up as XX000 is likely to be a real bug, whereas if
we don't, the things that we're not concerned about have to be
filtered out by some other method, probably involving a human being.
If the filter that human being has to apply further involves reading
Tom Lane's mind and knowing what he will think about a particular
report, or alternatively asking him, it just makes complicated
something that we could have made simple.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-05-13 20:27:44 Re: Teaching users how they can get the most out of HOT in Postgres 14
Previous Message Mark Dilger 2021-05-13 19:30:43 Re: Granting control of SUSET gucs to non-superusers