On Mon, Jun 13, 2011 at 7:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> But my point is: any FDW code Dave rights now is not going to have
> major dependencies on the planner that will potentially require
> extensive reworking in the future because it won't have any real
> dependencies on the planner at all. It's not like we have an API and
> we're planning to change it: what we have to talk to the planner right
> now is little more than a stub. Unless I miss my guess, the work Dave
> et al are doing right now is just around making PostgreSQL talk to X,
> for various values of X. Now, if we expose an API to allow qual
> pushdown, all of those FDWs will need to be updated if they want to
> support qual pushdown (and maybe even a little bit, if they don't).
> But the work of, say, making it possible to translate MySQL tuples
> into PostgreSQL tuples doesn't seem likely to be wasted.
Right - that's what I thought Tom was saying would be junked.
I've already implemented some simple qual pushdown in the redis FDW,
and am planning to do something similar for MySQL - however I won't be
surprised if I have to rewrite redisGetQual in
https://github.com/dpage/redis_fdw/blob/master/redis_fdw.c for
example.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
