On Fri, Jul 19, 2013 at 1:46 PM, David Fetter <da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
