Horton

Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

Hannu Krosing <hannu@2ndquadrant.com>

View thread View on postgr.es
From: Hannu Krosing <hannu@2ndQuadrant.com>
To: Daniel Farina <drfarina@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Greg Smith <greg@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Daniel Farina <dfarina@truviso.com>, pgsql-hackers@postgresql.org
Date: 2009-11-24T10:50:48Z
Lists: pgsql-hackers 
On Tue, 2009-11-24 at 02:37 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > Hello
> >
> > I thing, so this patch is maybe good idea. I am missing better
> > function specification. Specification by name isn't enough - we can
> > have a overloaded functions. This syntax doesn't allow to use explicit
> > cast - from my personal view, the syntax is ugly - with type
> > specification we don't need to keyword FUNCTION
> 
> As long as things continue to support the INTERNAL-type behavior for
> extremely low overhead bulk transfers I am open to suggestions about
> how to enrich things...but how would I do so under this proposal?
> 
> I am especially fishing for suggestions in the direction of managing
> state for the function between rows though...I don't like how the
> current design seems to scream "use a global variable."

Can't you use existing aggregate function design ?

CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
    SFUNC = sfunc,
    STYPE = state_data_type
    [ , FINALFUNC = ffunc ]
    [ , INITCOND = initial_condition ]
    [ , SORTOP = sort_operator ]
)

and maybe use additional INITFUNC=, if you need it for dblink type
things which don't do connection management it automatically like
pl/proxy does.

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