On Wed, Dec 04, 2013 at 03:04:31PM -0500, Tom Lane wrote:
> David Fetter <david@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 <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