Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)
On Fri, Jun 29, 2018 at 12:06 PM, Alvaro Herrera wrote: > Okay, pushed that way. > > We can redo this if/when we add support for cloning BEFORE row triggers, > which are going to need the trigger link info, I suspect. Yeah, having an explicit representation seems less likely to be fragile. Following dependencies might not work if there's an extra dependency that you aren't expecting for some reason. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)
On 2018-Jun-29, Amit Langote wrote: > On 2018/06/29 6:23, Peter Eisentraut wrote: > > On 6/28/18 22:52, Alvaro Herrera wrote: > >>> Couldn't psql chase the pg_depend links to find inherited triggers? > >> > >> Yeah, I thought this would be exceedingly ugly, but apparently it's not > >> *that* bad -- see the attached patch, which relies on the fact that > >> triggers don't otherwise depend on other triggers. We don't use this > >> technique elsewhere in psql though. > > > > Yeah, relying on pg_depend to detect relationships between catalog > > objects is a bit evil. We do use this for detecting sequences linked to > > tables, which also has its share of problems. Ideally, there would be a > > column in pg_trigger, perhaps, that makes this link explicit. But we > > are looking here for a solution without catalog changes, I believe. > > +1 if that gets the job done. Okay, pushed that way. We can redo this if/when we add support for cloning BEFORE row triggers, which are going to need the trigger link info, I suspect. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)
On 2018/06/29 6:23, Peter Eisentraut wrote: > On 6/28/18 22:52, Alvaro Herrera wrote: >>> Couldn't psql chase the pg_depend links to find inherited triggers? >> >> Yeah, I thought this would be exceedingly ugly, but apparently it's not >> *that* bad -- see the attached patch, which relies on the fact that >> triggers don't otherwise depend on other triggers. We don't use this >> technique elsewhere in psql though. > > Yeah, relying on pg_depend to detect relationships between catalog > objects is a bit evil. We do use this for detecting sequences linked to > tables, which also has its share of problems. Ideally, there would be a > column in pg_trigger, perhaps, that makes this link explicit. But we > are looking here for a solution without catalog changes, I believe. +1 if that gets the job done. Thanks, Amit
Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)
On 6/28/18 22:52, Alvaro Herrera wrote: >> Couldn't psql chase the pg_depend links to find inherited triggers? > > Yeah, I thought this would be exceedingly ugly, but apparently it's not > *that* bad -- see the attached patch, which relies on the fact that > triggers don't otherwise depend on other triggers. We don't use this > technique elsewhere in psql though. Yeah, relying on pg_depend to detect relationships between catalog objects is a bit evil. We do use this for detecting sequences linked to tables, which also has its share of problems. Ideally, there would be a column in pg_trigger, perhaps, that makes this link explicit. But we are looking here for a solution without catalog changes, I believe. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)
On 6/27/18 23:01, Alvaro Herrera wrote: > Another angle is that we're already in beta3 and there may be concerns > about altering catalog definition this late in the cycle. Anybody? > Maybe psql can just match tgisinternal triggers by name, and if one > match occurs then we assume it's a clone that should be listed as a > partition trigger. Couldn't psql chase the pg_depend links to find inherited triggers? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)
On 2018-Jun-28, David Rowley wrote: > On 28 June 2018 at 09:01, Alvaro Herrera wrote: > > Another angle is that we're already in beta3 and there may be concerns > > about altering catalog definition this late in the cycle. Anybody? > > Maybe psql can just match tgisinternal triggers by name, and if one > > match occurs then we assume it's a clone that should be listed as a > > partition trigger. > > Are catversion bumps really a huge problem in beta? Looks like there > were quite a few during the v10 cycle. Hm, I remember they were somewhat of a big deal. Maybe it's not so anymore and just can pg_upgrade easily? Of course, once a beta contains one, and subsequent ones before the next beta are "free". Your patch for partition pruning will also require one, by the looks, so I guess it's pretty much settled ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Listing triggers in partitions (was Re: Remove mention in docs that foreign keys on partitioned tables)
On 28 June 2018 at 09:01, Alvaro Herrera wrote: > Another angle is that we're already in beta3 and there may be concerns > about altering catalog definition this late in the cycle. Anybody? > Maybe psql can just match tgisinternal triggers by name, and if one > match occurs then we assume it's a clone that should be listed as a > partition trigger. Are catversion bumps really a huge problem in beta? Looks like there were quite a few during the v10 cycle. $ git log REL_10_BETA2..REL_10_BETA3 --oneline -- src\include\catalog\catversion.h | wc -l 1 $ git log REL_10_BETA1..REL_10_BETA2 --oneline -- src\include\catalog\catversion.h | wc -l 9 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
