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