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