From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED - file_fdw |
Date: | 2010-12-14 03:01:36 |
Message-ID: | AANLkTi=-6vSzZiWzcEbjV4zedFyyWxaG_w3mJk0VGT2_@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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:
>> I think that exposing the guts of COPY to the open air is a bad idea.
I don't want to export the details, too.
> 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.
BTW, we might have another choice instead of GetCopyExecutorState()
because the EState will be used only for ResetPerTupleExprContext()
in file_fdw. If NextCopyFrom() returns a HeapTuple instead of values
and nulls arrays, we could hide EState in NextCopyFrom().
--
Itagaki Takahiro
Attachment | Content-Type | Size |
---|---|---|
copy_export-20101214.diff | application/octet-stream | 49.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-12-14 03:02:11 | Re: pg_execute_from_file, patch v10 |
Previous Message | Robert Haas | 2010-12-14 02:51:40 | Re: SQL/MED - core functionality |