Re: patch: SQL/MED(FDW) DDL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, SAKAMOTO Masahiko <sakamoto(dot)masahiko(at)oss(dot)ntt(dot)co(dot)jp>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: SQL/MED(FDW) DDL
Date: 2010-10-01 14:54:47
Message-ID: 15684.1285944887@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)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 --- 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.

What we need is an API that lets the FDW decide which quals it will take
responsibility for enforcing. What happens beyond that point is not
ours to decide.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-10-01 14:59:11 Re: Patch author name on commitfest page
Previous Message Robert Haas 2010-10-01 14:47:11 Re: I: About "Our CLUSTER implementation is pessimal" patch