On 15 February 2017 at 20:26, David Fetter <da...@fetter.org> wrote: > When an UPDATE can't happen, there are often ways to hint at > what went wrong and how to correct it. Violating a uniqueness > constraint would be one example. > > When an UPDATE can't happen and the depth of the subtree is a > plausible candidate for what prevents it, there might be a way to say > so. > > Let's imagine a table called log with partitions on "stamp" log_YYYY > and subpartitions, also on "stamp", log_YYYYMM. If you do something > like > > UPDATE log_2017 SET "stamp"='2016-11-08 23:03:00' WHERE ... > > it's possible to know that it might have worked had the UPDATE taken > place on log rather than on log_2017. > > Does that make sense, and if so, is it super invasive to HINT that?
Yeah, I think it should be possible to find the root partition with the help of pg_partitioned_table, and then run ExecFindPartition() again using the root. Will check. I am not sure right now how involved that would turn out to be, but I think that logic would not change the existing code, so in that sense it is not invasive. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
