Re: SQL/MED - file_fdw

From: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED - file_fdw
Date: 2010-12-14 06:31:37
Message-ID: 20101214153135.A5F4.6989961C@metrosystems.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 14 Dec 2010 12:01:36 +0900
Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Tue, Dec 14, 2010 at 01:25, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> > On 12/13/2010 11:12 AM, Tom Lane wrote:
> > In that case I guess I'll need to do what Shigeru-san has done, and copy
> > large parts of copy.c.
>
> I found file_fdw would require the executor state in CopyState and
> the error callback function. I revised the patch to export them.
> Now 5 functions are exported from copy.c:
>
> - BeginCopyFrom(rel, filename, attnamelist, options) : CopyState
> - EndCopyFrom(cstate) : void
> - NextCopyFrom(cstate, OUT values, OUT nulls, OUT tupleOid) : bool
> - GetCopyExecutorState(cstate) : EState *
> - CopyFromErrorCallback(arg)
>
> Are they enough, Shigeru-san? Note that the internal CopyFrom() is
> now implemented only with them, so I think file_fdw is also possible.

In addition to above, ResetCopyFrom() is necessary to support nested
loops which inner node is a ForeignScan.

On the other hand, I think that MarkPos()/RestrPos() wouldn't be
necessary until ForeignScan supports ordered output. ForeignScan
can't become direct child of MergeJoin because ForeignScan is not an
ordered scan, at least in current SQL/MED implementation.

Regards,
--
Shigeru Hanada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2010-12-14 06:51:18 Re: SQL/MED - file_fdw
Previous Message Tom Lane 2010-12-14 06:29:20 Re: hstores in pl/python