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

So you have for Postgres: Node(foo) => $1, but to other databases
perhaps :field1. But most of the other code can be shared..


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

Attachment: signature.asc
Description: Digital signature

Reply via email to