On Tue, 2009-11-24 at 02:37 -0800, Daniel Farina wrote: > On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers