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