Re: exposing COPY API

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: exposing COPY API
Date: 2011-02-04 02:02:39
Message-ID: AANLkTikq589xHenDQqpyK5GOkh_mAnbg4LdhhPchj_Rp@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 4, 2011 at 09:48, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> I'd like to be able to add a callback function to construct the values for
> the tuple. So it would become something like:
>   typedef void (*copy_make_values) (CopyState cstate, NumFieldsRead int);

You can do nothing interesting in the callback probably
because the details of CopyState is not exported yet.
Also, we should pass through user context for such kind of callback.
The prototype of would have "void *userdata".

> Of course, I want this so I could construct a text array from the read in
> data, but I could also imagine a foreign data wrapper wanting to mangle the
> data before handing it to postgres, say by filling in a field or hashing it.

Could you explain the actual use-cases and examples? I think we need to have
SQL-level extensibility if we provide such flexibility. I guess typical users
don't want to write functions with C for each kind of input files.

Note that pg_bulkload has a similar feature like as:
CREATE FUNCTION my_function(...) RETURNS record AS ...;
COPY tbl FROM 'file' WITH (make_record_from_line = my_function)

--
Itagaki Takahiro

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-04 02:05:52 Re: [HACKERS] Slow count(*) again...
Previous Message david 2011-02-04 01:37:14 Re: [HACKERS] Slow count(*) again...