On Fri, Oct 01, 2010 at 10:54:47AM -0400, Tom Lane wrote: > David Fetter <da...@fetter.org> writes: > > On Thu, Sep 30, 2010 at 10:29:56PM -0400, Robert Haas wrote: > >> Yeah, that might be better. Is it reasonable to assume we always > >> want to push down as much as possible, or do we need to think about > >> local work vs. remote work trade-offs? > > > In cases where the foreign side is not super reliable for correctness, > > I'd say there's a good case for not trusting it. Some of the Oracle > > properties are like this. I suppose we might want to make "trust the > > other side to handle pushed quals" optional somehow, but I'm not > > exactly sure how. > > ISTM that such decisions would be embedded in the FDW
s/embedded in/& and overrides communicable to/ In an upcoming version of DBI-Link, I've got some code that allows transformations between types on PostgreSQL and foreign sources, for now when they have the same name. The transformations are implemented on the PostgreSQL side, although I a plan for (optionally) pushing them to the foreign side. There's an input transformation and an output transformation, both of which default to the identity transformation, i.e. "do nothing." These transformations are over-ridable at the following levels, with the finer-grained one taking precedence over the coarser should there be more than one user-supplied transformation: - database type (Oracle, CSV, etc.) - catalog (Database cluster in PostgreSQL parlance, i.e. everything served on a single host/port combination. DB2 actually implements this under that name.) - database - schema - table - column > --- it's unlikely that the FDW for Oracle would look even a little > bit like the one for Postgres anyway, so contemplating ways to > parameterize them seems a rather useless exercise. See above for a parameterization :) Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
