On Mon, Aug 5, 2013 at 12:21 PM, Tom Lane wrote:
> David Gudeman writes:
>> For those who don't want to go to the link to see what I'm talking
>> about with query rewrites, I thought I'd give a brief description.
>> Foreign data wrappers currently do all of
anguage constructs so the
pass-through query has to be available in Postgresql SQL.
My current implementation of this uses a plugin that hooks into
planner_hook, but I'm hoping that I can get some support for adding
the query rewriting as callback functions for the FDW s
On Tue, Jul 30, 2013 at 10:22 PM, Tom Lane wrote:
> David Fetter writes:
>> On Tue, Jul 30, 2013 at 04:40:38PM -0700, David Gudeman wrote:
>>> When you write an application involving foreign tables, you frequently
>>> end up with queries that are just too inefficient
already constructed. But this probably requires
less work for the authors of foreign data wrappers and it doesn't
materialize the results of the foreign query unnecessarily.
Any suggestions or hints?
Regards,
David Gudeman
http://unobtainabol.blogspot.com
--
Sent via pgsql-hackers mailing
The primary change we made to Postgres in order to support our own
version of foreign data wrappers was a row-at-a-time execution for
table functions. In standard Postgres, when you execute a table
function, it gathers all of the rows at once and stuffs them into a
buffer in order to support cursor
on't think that it's mature enough for what I need to do.
Regards,
David Gudeman
On Mon, Apr 22, 2013 at 11:27 AM, David Gudeman wrote:
> Re-reading my first email I thought it was a little confusing, so here
> is some clarification. In GetForeignPlan, tlist seems to be a target
&g
Can anyone confirm or deny these assumptions?
Thanks.
On Sun, Apr 21, 2013 at 6:57 PM, David Gudeman wrote:
>
> A few years ago I wrote a roll-your-own foreign-data-wrapper system for
> Postgres because Postgres didn't have one at the time (some details here
> (http://u
7;d hate to go to the
trouble of implementing and testing it only to find that I'm making some
bogus assumptions.
Thanks,
David Gudeman
