Re: SQL/MED - file_fdw - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: SQL/MED - file_fdw
Date
Msg-id AANLkTinpXTR4WOXAEEa_A6y3U9_+cT+v1b222HJPgm5k@mail.gmail.com
Whole thread Raw
In response to Re: SQL/MED - file_fdw  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: SQL/MED - file_fdw  (Shigeru HANADA <hanada@metrosystems.co.jp>)
Re: SQL/MED - file_fdw  (Shigeru HANADA <hanada@metrosystems.co.jp>)
List pgsql-hackers
On Mon, Dec 20, 2010 at 20:42, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> I added comments and moved some setup codes for COPY TO to BeginCopyTo()
> for maintainability. CopyTo() still contains parts of initialization,
> but I've not touched it yet because we don't need the arrangement for now.

I updated the COPY FROM API patch.
- GetCopyExecutorState() is removed because FDWs will use their own context.

The patch just rearranges codes for COPY FROM to export those functions.
It also modifies some of COPY TO codes internally for code readability.
- BeginCopyFrom(rel, filename, attnamelist, options)
- EndCopyFrom(cstate)
- NextCopyFrom(cstate, OUT values, OUT nulls, OUT tupleOid)
- CopyFromErrorCallback(arg)

Some items to be considered:
- BeginCopyFrom() could receive filename as an option instead of a separated
argument. If do so, file_fdw would be more simple, but it's a change only for
file_fdw. COPY commands in the core won't be improved at all.
- NextCopyFrom() returns values/nulls arrays rather than a HeapTuple. I expect
the caller store the result into tupletableslot with ExecStoreVirtualTuple().
It is designed for performance, but if the caller always needs an materialized
HeapTuple, HeapTuple is better for the result type.

--
Itagaki Takahiro

Attachment

pgsql-hackers by date:

Previous
From: Joel Jacobson
Date:
Subject: pov and tsort
Next
From: Bruce Momjian
Date:
Subject: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE