Re: SQL/MED - file_fdw

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org, hanada(at)metrosystems(dot)co(dot)jp
Subject: Re: SQL/MED - file_fdw
Date: 2011-02-09 05:55:26
Message-ID: AANLkTimfZE1bLXFfuV9TPihGOR7Uq=Z=a=2kTusG2PJk@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 9, 2011 at 03:49, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> A new exported function is named as NextCopyFromRawFields.
> Seems a bit incongruous to handle the OID column in that function.  That part
> fits with the other per-column code in NextCopyFrom().

Hmmm, I thought oid columns should be separated from user columns, but it
might be a confusing interface. I removed the explicit oid output from
NextCopyFromRawFields. file_fdw won't use oids at all in any cases, though.

> The code still violates the contract of ExecEvalExpr() by calling it with
> CurrentMemoryContext != econtext->ecxt_per_tuple_memory.

I'm not sure whether we have such contract because the caller might
want to get the expression result in long-lived context. But anyway
using an external ExprContext looks cleaner. The new prototype is:

bool NextCopyFrom(
[IN] CopyState cstate, ExprContext *econtext,
[OUT] Datum *values, bool *nulls, Oid *tupleOid)

Note that econtext can be NULL if no default values are used.
Since file_fdw won't use default values, we can just pass NULL for it.

> Sorry, I missed a lot of these memory details on my first couple of reviews.

You did great reviews! Thank you very much.

--
Itagaki Takahiro

Attachment Content-Type Size
copy_export-20110209.patch application/octet-stream 49.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-02-09 06:02:23 Re: Named restore points
Previous Message Jeff Davis 2011-02-09 05:52:13 Re: REVIEW Range Types