Обсуждение: Foreign Tables as Partitions
Folks, Please find attached a PoC patch to implement $subject. So far, with a lot of help from Andrew Gierth, I've roughed out an implementation which allows you to ALTER FOREIGN TABLE so it inherits a local table. TBD: CREATE FOREIGN TABLE ... INHERITS ..., docs, regression testing, etc., etc. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Вложения
On Thu, Jul 18, 2013 at 8:56 PM, David Fetter <david@fetter.org> wrote: > Please find attached a PoC patch to implement $subject. > > So far, with a lot of help from Andrew Gierth, I've roughed out an > implementation which allows you to ALTER FOREIGN TABLE so it inherits > a local table. > > TBD: CREATE FOREIGN TABLE ... INHERITS ..., docs, regression testing, > etc., etc. I think this could be useful, but it's going to take more than a three-line patch. Removing code that prohibits things is easy; what's hard is verifying that nothing else breaks as a result. And I bet it does. This functionality was actually present in the original submission for foreign tables. I ripped it out before commit because I didn't think all of the interactions with other commands had been adequately considered. But I think they did consider it to some degree, which this patch does not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Jul 19, 2013 at 11:41:14AM -0400, Robert Haas wrote: > On Thu, Jul 18, 2013 at 8:56 PM, David Fetter <david@fetter.org> wrote: > > Please find attached a PoC patch to implement $subject. > > > > So far, with a lot of help from Andrew Gierth, I've roughed out an > > implementation which allows you to ALTER FOREIGN TABLE so it inherits > > a local table. > > > > TBD: CREATE FOREIGN TABLE ... INHERITS ..., docs, regression testing, > > etc., etc. > > I think this could be useful, but it's going to take more than a > three-line patch. Of course! > Removing code that prohibits things is easy; what's hard is > verifying that nothing else breaks as a result. And I bet it does. It may well. I see our relations eventually being as equivalent as their definitions permit (views, materialized or not, foreign tables, etc.), and this as work toward that. Yes, it's normative, and we may never fully get there, but I'm pretty sure it's worth working towards. > This functionality was actually present in the original submission > for foreign tables. I ripped it out before commit because I didn't > think all of the interactions with other commands had been > adequately considered. But I think they did consider it to some > degree, which this patch does not. A ref to the patch as submitted & patch as applied would help a lot :) Were there any particular things you managed to break with the patch as submitted? Places you thought would be soft but didn't poke at? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Fri, Jul 19, 2013 at 1:46 PM, David Fetter <david@fetter.org> wrote: >> This functionality was actually present in the original submission >> for foreign tables. I ripped it out before commit because I didn't >> think all of the interactions with other commands had been >> adequately considered. But I think they did consider it to some >> degree, which this patch does not. > > A ref to the patch as submitted & patch as applied would help a lot :) The patch as committed is 0d692a0dc9f0e532c67c577187fe5d7d323cb95b. I suspect you can find the patch as submitted by going and figuring out which CommitFest that was part of and working it out from there. > Were there any particular things you managed to break with the patch > as submitted? Places you thought would be soft but didn't poke at? I think there was *some* discussion of this at the time. The basic issue was to make sure all the commands that could encounter foreign tables with this change but not without it behaved sanely. This would include all variants of ALTER TABLE as well as ANALYZE and any other utility commands that might view it as within their remit to recurse to child tables. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company