On Sat, Mar 10, 2012 at 11:38:51AM -0500, Tom Lane wrote: > Shigeru Hanada <shigeru.han...@gmail.com> writes: > > Thanks for the review. Agreed to write own depraser for pgsql_fdw > > which handles nodes which can be pushed down. Every SQL-based FDW > > which constructs SQL statement for each local query would need such > > module inside. > > Yeah. That's kind of annoying, and the first thing you think of is that > we ought to find a way to share that code somehow. But I think it's > folly to try to design a shared implementation until we have some > concrete implementations to compare. An Oracle FDW, for instance, would > need to emit SQL code with many differences in detail from pgsql_fdw. > It's not clear to me whether a shared implementation is even practical, > but for sure I don't want to try to build it before we've done some > prototype single-purpose implementations.
FWIW, this sounds like the "compiler" mechanism in SQLalchemy for turning SQL node trees into strings. The basic idea is you define functions for converting nodes to strings. Stuff like "And" and "Or" works for every database, but then "dialects" can override different things. So you have for Postgres: Node(foo) => $1, but to other databases perhaps :field1. But most of the other code can be shared.. http://docs.sqlalchemy.org/en/latest/core/compiler.html In my experience it works well for generating custom constructs. They have compilers for 11 different database engines, so it seems flexible enough. Mind you, they also handle DDL mapping (where most of the variation is) and datatype translations, which seems a lot further than we need here. Have a nice day, -- Martijn van Oosterhout <klep...@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
signature.asc
Description: Digital signature
