On Wed, May 17, 2017 at 10:13 AM, Kevin Grittner <kgri...@gmail.com> wrote: > On Tue, May 16, 2017 at 4:50 PM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> >> I'm about to post a much simpler patch that collects uniform tuples >> from children, addressing the reported bug, and simply rejects >> transition tables on row-triggers on tables that are in either kind of >> inheritance hierarchy. More soon... > > I agree that we can safely go that far, but not farther. Thanks!
Here is that patch. Thoughts? On Wed, May 10, 2017 at 3:41 PM, Robert Haas <robertmh...@gmail.com> wrote: > Hmm. What if the partitioning hierarchy contains foreign tables? No tuples are collected from partitions that are foreign tables. See the attached demonstration. I wasn't sure whether and if so where to include that in the regression tests because it needs a contrib module. Robert and I discussed this off-list and came up with some options: (1) document that as the current behaviour (where?), (2) figure out how to prevent that situation from arising, (3) raise some kind of runtime error if foreign transition tuples need to be collected. Option 2 would seem to require us to lock the whole chain of ancestors to check for statement-level triggers with transition tables, which seems unpleasant, and option 3 is conceptually similar to the execution time insertion failure. It's debatable wither 3 or 1 is more surprising or inconvenient to users. I vote for option 1 as a stop-gap measure (and I hope that someone will soon fix transition tuple capture for foreign tables generally). However, it's a bit inconsistent that we explicitly reject triggers with transition tables on foreign tables directly, but let them silently fail to capture anything when they're indirectly accessed via a parent relation. Thoughts? -- Thomas Munro http://www.enterprisedb.com
transition-tables-vs-foreign-partitions.sql
Description: Binary data
transition-tuples-from-child-tables-v4.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
