Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Date
Msg-id 1259051917.30357.60.camel@hvost1700
Whole thread Raw
In response to Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION  (Daniel Farina <dfarina@truviso.com>)
Responses Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
List pgsql-hackers
On Mon, 2009-11-23 at 16:25 -0800, Daniel Farina wrote:
> On Mon, Nov 23, 2009 at 4:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > pgsql-hackers had some preliminary discussions a couple months back
> > on refactoring COPY to allow things like this --- see the thread
> > starting here:
> > http://archives.postgresql.org/pgsql-hackers/2009-09/msg00486.php
> > While I don't think we arrived at any final decisions, I would like
> > to know how this design fits in with what was discussed then.
> 
> This seems to be about importing/ingress, whereas this patch is about
> exporting/egress...it is an interesting question on how much parsing
> to do before on the ingress side before handing a row to a function
> though, 

My suggestion for 

COPY func(rowtype) FROM stdin;

would be to pass the function a fully processed row of that type with
all fields resolved and converted to right types.

it may be useful to also have forms like

COPY func(text) FROM stdin;

and

COPY func(bytea[]) FROM stdin;

for getting a less processed input

> should we try to make these kinds of operations a bit more
> symmetrical.



-- 
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability   Services, Consulting and Training




pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: Partitioning option for COPY
Next
From: Hannu Krosing
Date:
Subject: Re: [GENERAL] Updating column on row update