Re: [HACKERS] Surjective functional indexes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Surjective functional indexes
Date
Msg-id 20190114230918.fhp6wktbhg6pjnyw@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Surjective functional indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Surjective functional indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2019-01-14 18:03:24 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-11-07 14:25:54 -0500, Tom Lane wrote:
> >> In short, it seems likely to me that large parts of this patch need to
> >> be pulled out, rewritten, and then put back in different places than
> >> they are today.  I'm not sure if a complete revert is the best next
> >> step, or if we can make progress without that.
> 
> > We've not really made progress on this. I continue to think that we
> > ought to revert this feature, and then work to re-merge it an
> > architecturally correct way afterwards.  Other opinions?
> 
> Given the lack of progress, I'd agree with a revert.  It's probably
> already going to be a bit painful to undo due to subsequent changes,
> so we shouldn't wait too much longer.

Yea, the reason I re-encountered this is cleaning up the pluggable
storage patch. Which certainly would make this revert harder...


> Do we want to revert entirely, or leave the "recheck_on_update" option
> present but nonfunctional?

I think it depends a bit on whether we want to revert in master or
master and 11. If only master, I don't see much point in leaving the
option around. If both, I think we should (need to?) leave it around in
11 only.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Surjective functional indexes
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Surjective functional indexes