Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id C8F76133729E for ; Fri, 1 Oct 2010 12:38:29 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 74279-01 for ; Fri, 1 Oct 2010 15:38:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from fetter.org (mail.fetter.org [64.81.66.25]) by mail.postgresql.org (Postfix) with ESMTP id F3CDE133655C for ; Fri, 1 Oct 2010 12:38:21 -0300 (ADT) Received: by fetter.org (Postfix, from userid 500) id 13C4EFBCB5C; Fri, 1 Oct 2010 08:38:21 -0700 (PDT) Date: Fri, 1 Oct 2010 08:38:21 -0700 From: David Fetter To: Tom Lane Cc: Robert Haas , Alvaro Herrera , SAKAMOTO Masahiko , Itagaki Takahiro , Heikki Linnakangas , pgsql-hackers Subject: Re: patch: SQL/MED(FDW) DDL Message-ID: <20101001153821.GC6319@fetter.org> References: <4C9C6B86.3040102@enterprisedb.com> <4CA03EBA.4010203@oss.ntt.co.jp> <1285768919-sup-3750@alvh.no-ip.org> <20101001142725.GB6319@fetter.org> <15684.1285944887@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15684.1285944887@sss.pgh.pa.us> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/50 X-Sequence-Number: 171090 On Fri, Oct 01, 2010 at 10:54:47AM -0400, Tom Lane wrote: > David Fetter 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 http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@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