On Wed, Dec 04, 2013 at 03:04:31PM -0500, Tom Lane wrote: > David Fetter <da...@fetter.org> writes: > > The idea here is that such a happy situation will not obtain until > > much later, if ever, and meanwhile, we need a way to get things > > accomplished even if it's inelegant, inefficient, etc. The > > alternative is that those things simply will not get accomplished > > at all. > > If that's the argument, why not just use dblink or dbilink, and be > happy? This discussion sounds a whole lot like it's trending to a > conclusion of wanting one of those in core, which is not where I'd > like to end up.
Telling people who've already installed and configured an FDW that for perfectly ordinary expected functionality they'll need to install yet another piece of software, configure it, keep its configuration in sync with the FDW configuration, etc., is just a ridiculous. So yes, we do need this functionality and it does need to be part of our FDW implementation. Just exactly where we draw the line between built-ins and APIs is the conversation I thought we were having. The minimal thing would be providing database handles per SQL/MED and a few tools to manipulate same. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
