Re: MERGE SQL statement for PG12
| От | Pavan Deolasee |
|---|---|
| Тема | Re: MERGE SQL statement for PG12 |
| Дата | |
| Msg-id | CABOikdNEwrimsgzR25KS=DSVr=5sHi0qAM1qptaCMZoG7F_DwA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: MERGE SQL statement for PG12 (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
| Ответы |
Re: MERGE SQL statement for PG12
Re: MERGE SQL statement for PG12 |
| Список | pgsql-hackers |
Hi Tomas,
On Thu, Nov 22, 2018 at 10:03 PM Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
I think not going through nodeModifyTable and having a separate
nodeMerge.c makes sense. It might result in some code being duplicated,
but I suppose that code can be shared (wrapped as a function, moved to
some file shared by the two nodes). I wouldn't expect the result to be
particularly ugly, at least not compared to how nodeModifyTable is
twisted with the current patch.
- Noticed that partColsUpdated is not set correctly in case of MERGE since we never get to call expand_partitioned_rtentry() for the partition table in case of MERGE. This right now does not cause significant problem, since we initialise the required states by other means. But we should fix this.
- I am not entirely sure if the tuple-conversion business is bug-free for MERGE, post this rebase. Since this code has changed quite a bit in the master, I will have another look and check. The tests do not show any issues, but that could also be because of lack of tests in this area with respect to MERGE.
- I am not sure if I adopted the slot related changes introduced by 1a0586de3657cd35581f0639c87d5050c6197bb7.
Thanks,
Pavan
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: