Re: Rethinking opclass member checks and dependency strength - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rethinking opclass member checks and dependency strength
Date
Msg-id 2023114.1596316622@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rethinking opclass member checks and dependency strength  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
List pgsql-hackers
Anastasia Lubennikova <a.lubennikova@postgrespro.ru> writes:
> On 31.03.2020 23:45, Tom Lane wrote:
>> Still haven't got a better naming idea, but in the meantime here's
>> a rebase to fix a conflict with 612a1ab76.

> Maybe "amadjustmembers" will work?

Not having any better idea, I adopted that one.

> I've looked through the patch and noticed this comment:
> +                /* Probably we should throw error here */

> I suggest adding an ERROR or maybe Assert, so that future developers 
> wouldn't
> forget about setting dependencies. Other than that, the patch looks good 
> to me.

I'd figured that adding error checks could be left for a second pass,
but there's no strong reason not to insert these particular checks
now ... and indeed, doing so showed me that the patch hadn't been
updated to cover the recent addition of opclass options procs :-(.
So I fixed that and pushed it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: psql - improve test coverage from 41% to 88%
Next
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM