Let me rephrase this:
Let’s remove my motivations and use cases from this conversation….
Why is that a bad idea of rewriting the query before it reaches transform/analyze (without ever accessing the catalog)?
If that flexibility is acceptable to you, where would be the best place to put it in?
Thanks, David
2014.02.14. dátummal, 10:30 időpontban David Beck <dbeck@starschema.net> írta:
> Thanks for the reply. There are two things I think I’ve been misunderstood:
>
> 1, the point is to do the rewrite without and before catalog access
> 2, I do want to push the join to the source and equally important pushing the where conditions there
>
> Best regards, David
>
>
> 2014.02.13. dátummal, 21:22 időpontban Tom Lane <tgl@sss.pgh.pa.us> írta:
>
>> David Beck <dbeck@starschema.net> writes:
>>> I have table like data structures in the source system for the FDW I work on.
>>> These tables are sometimes too big and the source system is able to filter and join them with limitations, thus it
isnot optimal to transfer the data to Postgres.
>>> At the same time I want the users to think in terms of the original tables.
>>
>>> The idea is to rewrite the SQL queries like this:
>>
>>> “SELECT * FROM tableA a, tableB b WHERE a.id=b.id AND a.col1=1234 AND b.col2=987”
>>
>>> to:
>>
>>> “SELECT * FROM fdw_tableA_tableB ab WHERE ab.col1=1234 AND ab.col2=987”
>>
>> TBH this sounds like a spectacularly bad idea, especially in the place and
>> way you propose to do it. You can't even do catalog access safely where
>> you've put that hook, not to mention that there are many other places
>> where queries can be submitted. But more generally, an FDW should not
>> operate in the way you're describing.
>>
>> We do lack support for pushing joins to the foreign server, and that needs
>> to be addressed; but we need to do it in the planner, not by kluging the
>> query somewhere upstream of that.
>>
>> regards, tom lane
>
