Right, but I think he needs the "it's not easy, here's the whole
workflow" overview first.
Ross
--
Ross Reedstrom, Ph.D. reeds...@rice.edu
Systems Engineer & Admin, Research Scientistphone: 713-348-6166
Connexions http://cnx.org
On Mon, Jun 13, 2011 at 8:44 PM, Tom Lane wrote:
> Dave Page writes:
>> I've already implemented some simple qual pushdown in the redis FDW,
>> and am planning to do something similar for MySQL - however I won't be
>> surprised if I have to rewrite redisGetQual in
>> https://github.com/dpage/redi
(2011/06/13 21:30), Robert Haas wrote:
> Committed, with some additional word-smithing.
Thanks.
> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
> That would be a killer feature.
Yes, I would like to work on pgsql_fdw and other SQL/MED issues in 9.2
development cycle. I'm
Dave Page writes:
> I've already implemented some simple qual pushdown in the redis FDW,
> and am planning to do something similar for MySQL - however I won't be
> surprised if I have to rewrite redisGetQual in
> https://github.com/dpage/redis_fdw/blob/master/redis_fdw.c for
> example.
OK, *now*
On Mon, Jun 13, 2011 at 7:08 PM, Robert Haas wrote:
> But my point is: any FDW code Dave rights now is not going to have
> major dependencies on the planner that will potentially require
> extensive reworking in the future because it won't have any real
> dependencies on the planner at all. It's
Robert Haas writes:
> But my point is: any FDW code Dave rights now is not going to have
> major dependencies on the planner that will potentially require
> extensive reworking in the future because it won't have any real
> dependencies on the planner at all. It's not like we have an API and
> we
Dave Page writes:
> On Mon, Jun 13, 2011 at 6:56 PM, Tom Lane wrote:
>> I think we're talking past each other.
> Hmm, I wonder if you're correct (as usual :-p). I thought you were
> talking about the API as defined here:
> http://www.postgresql.org/docs/9.1/static/fdw-routines.html, not
> intern
On Mon, Jun 13, 2011 at 1:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
>>> BTW; it seems to me this should be documented, as it could really hack
>>> off developers. I can't see anything in the docs to imply the API
>>> might be radically red
On Mon, Jun 13, 2011 at 6:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
>>> BTW; it seems to me this should be documented, as it could really hack
>>> off developers. I can't see anything in the docs to imply the API
>>> might be radically red
Robert Haas writes:
> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
>> BTW; it seems to me this should be documented, as it could really hack
>> off developers. I can't see anything in the docs to imply the API
>> might be radically redesigned.
> And I'm still unconvinced that it's needed.
On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
> On Mon, Jun 13, 2011 at 5:29 PM, Christopher Browne
> wrote:
>> On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote:
>>> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
>>>
Yeah - MySQL is one of the ones I've been hacking on. It's h
On Mon, Jun 13, 2011 at 5:29 PM, Christopher Browne wrote:
> On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote:
>> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
>>
>>> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be
>>> motivated if its going to need a complete rewri
On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote:
> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
>
>> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be
>> motivated if its going to need a complete rewrite within a year
>> though. I'll still have to work on it, as I've
On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be
> motivated if its going to need a complete rewrite within a year
> though. I'll still have to work on it, as I've committed to giving
> talks on it, but others might not both
On Mon, Jun 13, 2011 at 4:38 PM, Andrew Dunstan wrote:
>
>
> On 06/13/2011 10:25 AM, Dave Page wrote:
>>
>>> Don't hold your breath. We'll probably be making enough changes in the
>>> FDW infrastructure (particularly planner support) that making an FDW
>>> work on both 9.1 and 9.2 would be an exe
On 06/13/2011 10:25 AM, Dave Page wrote:
Don't hold your breath. We'll probably be making enough changes in the
FDW infrastructure (particularly planner support) that making an FDW
work on both 9.1 and 9.2 would be an exercise in frustration, if it's
even possible.
Oh joy. There's a GSoC st
Dave Page writes:
> On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane wrote:
>> Oh, that's by no means a waste of time --- we need some examples to help
>> us figure out where the pain points are. I'm just saying that the best
>> ways to do things will probably change quite a bit as we introduce
>> solu
On Mon, Jun 13, 2011 at 10:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote:
>>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
That would be a killer feature
On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote:
>>> Don't hold your breath. We'll probably be making enough changes in the
>>> FDW infrastructure (particularly planner support) that making an FDW
>>> work on both 9.1 and 9
Dave Page writes:
> On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote:
>> Don't hold your breath. We'll probably be making enough changes in the
>> FDW infrastructure (particularly planner support) that making an FDW
>> work on both 9.1 and 9.2 would be an exercise in frustration, if it's
>> even
On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote:
>>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
That would be a killer feature.
Robert Haas writes:
> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote:
>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
>>> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
>>> That would be a killer feature.
>> Even more killer would be that it could be built/pa
On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote:
> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
>> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
>> That would be a killer feature.
>
> Even more killer would be that it could be built/packaged as an
> extension,
On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
> That would be a killer feature.
Even more killer would be that it could be built/packaged as an
extension, and use for 9.1 too ;-)
a.
--
Aidan Van Dyk
2011/6/13 Shigeru Hanada :
> Thanks for the review.
>
> (2011/06/12 13:21), Robert Haas wrote:
>> 2011/6/9 Shigeru Hanada:
>>> Attached patch includes fixes for FOREIGN TABLE documents:
>>
>> I committed the changes to ALTER FOREIGN TABLE, but I think the
>> changes to CREATE FOREIGN TABLE need mor
Thanks for the review.
(2011/06/12 13:21), Robert Haas wrote:
> 2011/6/9 Shigeru Hanada:
>> Attached patch includes fixes for FOREIGN TABLE documents:
>
> I committed the changes to ALTER FOREIGN TABLE, but I think the
> changes to CREATE FOREIGN TABLE need more thought. The first of the
> two h
2011/6/9 Shigeru Hanada :
> Attached patch includes fixes for FOREIGN TABLE documents:
I committed the changes to ALTER FOREIGN TABLE, but I think the
changes to CREATE FOREIGN TABLE need more thought. The first of the
two hunks you've proposed to add doesn't seem necessary to me, and the
second
Hi hackers,
At first I've posted to pgsql-docs but there is no reply at present.
http://archives.postgresql.org/pgsql-docs/2011-06/msg6.php
So I post revised patch to pgsql-hackers, because the patch is for
documents under development for 9.1 beta2. Please let me know if this
was wrong l
28 matches
Mail list logo
