On Tue, Feb 6, 2018 at 9:40 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> I think we can do that for MERGE too, assuming we actually understand
>
> (1) why each of the pieces is missing
>
> (2) what would it take to make it work
Right, I completely agree with that. For example, if we find that a
certain thing can't be supported without implementing global indexes
on partitions, then I have no problem saying "OK, that's not going to
be supported", because global indexes are a huge project unto
themselves. That's the same reason ON CONFLICT .. UPDATE isn't
supported on partitioned tables, and it's just as reasonable for this
patch as it is for that one. What we don't want is things that this
patch doesn't support because it would take a couple of days of work
and the people who wrote the patch were busy and didn't have a couple
of extra days. We routinely expect patch authors to plug gaps caused
by oversight or lack of round tuits, and this patch should be held to
the same standard.
In short, we don't have a hard and fast rule that every feature must
work with every other feature, but when it doesn't, the burden is on
the patch author to justify why that omission is reasonable. I know I
expended a lot of ink explaining why parallel query couldn't
reasonably be made to support writes.
> I plan to go through the patch and this thread over the couple of days,
> and summarize what the current status is (or my understanding of it).
> That is (a) what are the missing pieces, (b) why are they missing, (c)
> how we plan to address them in the future and (d) opinions on these
> issues expressed by others on this thread.
Thank you. That sounds fantastic.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company