Re: Fix inconsistencies for v12 (pass 2)
От | Alexander Lakhin |
---|---|
Тема | Re: Fix inconsistencies for v12 (pass 2) |
Дата | |
Msg-id | dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com обсуждение исходный текст |
Ответ на | Re: Fix inconsistencies for v12 (pass 2) (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Fix inconsistencies for v12 (pass 2)
|
Список | pgsql-hackers |
Hello Michael, 13.06.2019 11:10, Michael Paquier wrote: > On Wed, Jun 12, 2019 at 05:34:06PM +0300, Alexander Lakhin wrote: >> I can't see another inconsistencies for v12 for now, but there are some >> that appeared before. >> If this work can be performed more effectively or should be >> postponed/canceled, please let me know. > Note sure that it is much productive to have one patch with basically > one-liners in each one... Anyway.. As the proposed fixes are independent, I decided to separate them. I will make a single patch on next iteration. > All your suggestions are right. I do have one doubt for the > suggestion in execnodes.h: > @@ -1571,7 +1571,6 @@ typedef struct TidScanState > int tss_NumTids; > int tss_TidPtr; > ItemPointerData *tss_TidList; > - HeapTupleData tss_htup; > } TidScanState; > The last trace of tss_htup has been removed as of 2e3da03, and I see > no mention of it in the related thread. Andres, is that intentional > for table AMs to keep a trace of a currently-fetched tuple for a TID > scan or something that can be removed? The field is still > documented, so the patch is incomplete if we finish by removing the > field. And my take is that we should keep it. Yes, you're right. I've completed the patch for a possible elimination of the field. Best regards, Alexander
Вложения
В списке pgsql-hackers по дате отправления: