On Sun, May 11, 2014 at 4:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > The $64 question is whether we'd accept an implementation that fails > if the target table has children (ie, is partitioned). That seems > to me to not be up to the project's usual quality expectations, but > maybe if there's enough demand for a partial solution we should do so. > > It strikes me that a big part of the problem here is that the current > support for this case assumes that the children don't all have the > same rowtype. Which is important if you think of "child table" as > meaning "subclass in the OO sense". But for ordinary partitioning > cases it's just useless complexity, and ModifyTable isn't the only > thing that suffers from that useless complexity. > > If we had a notion of "partitioned table" that involved a restriction > that all the child tables have the exact same rowtype, we could implement > UPDATE/DELETE in a much saner fashion --- just one plan tree, not one > per child table --- and it would be possible to support UPDATE/DELETE > ORDER BY LIMIT with no more work than for the single-table case. > So that might shift the calculation as to whether we're willing to > accept a partial implementation.
None of the use cases I have in mind would ever (have to) use this on a parent table; in the worst case it might make sense to do it on the child tables individually. Personally, I think that just refusing to operate on tables with children is a reasonable start. I have no interest in working on improving partitioning, but I don't think pushing this feature back in the hopes that someone else will would help anyone. But definitely only my two cents on this issue. ♜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
