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
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 |