Re: exposing COPY API - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: exposing COPY API
Date
Msg-id AANLkTikq589xHenDQqpyK5GOkh_mAnbg4LdhhPchj_Rp@mail.gmail.com
Whole thread Raw
In response to exposing COPY API  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: exposing COPY API  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Fri, Feb 4, 2011 at 09:48, Andrew Dunstan <andrew@dunslane.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


pgsql-hackers by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]
Next
From: Andrew Dunstan
Date:
Subject: Re: exposing COPY API