Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
От | Robert Haas |
---|---|
Тема | Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator |
Дата | |
Msg-id | CA+TgmoaeNhZAM_=DG8AvEQQ-oy6OVK7_5H1nhdtoFxR4rq2G0A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Mar 25, 2016 at 12:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> We could resolve both of these issues by changing the semantics of >>>> OprUpdate so that it unconditionally does a CommandCounterIncrement >>>> after each update that it performs. IMO that would be a lot simpler >>>> and more bulletproof; it'd allow removal of a lot of these >>>> overly-tightly-reasoned cases. > >>> I tried this, but it did not seem to work. > >> Odd. If you post the revised patch, I'll try to chase down what's wrong. > > After playing with this, I'll bet you forgot that RemoveOperatorById would > need to re-fetch the target tuple if it got updated. We could > alternatively fix that by skipping updates on the tuple due to be deleted, > but that would convolute the logic in OperatorUpd, which didn't seem > worthwhile to me. > > I found some other stuff needing fixing (mostly typos in comments) and > also realized that we don't really need to bother with heap_modify_tuple > at all. I pushed it with those fixes. Cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: