Re: [HACKERS] Surjective functional indexes
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Surjective functional indexes |
Дата | |
Msg-id | 20190114230918.fhp6wktbhg6pjnyw@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Surjective functional indexes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Surjective functional indexes
|
Список | 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 по дате отправления: