On Mon, Jun 13, 2011 at 7:08 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
