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

From Daniel Farina
Subject Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Date
Msg-id 7b97c5a40911250943u4ff7df92m3215f48352d60959@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Tue, Nov 24, 2009 at 10:39 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> yes - it is two features - and should be solved independently

There are some common problems though.  I was thinking about this with
some mind towards my existing mental model of thinking of specifying
some parameters up-front and getting a stream of records or bytes
(depending on what feature you are referring to) as a form of
currying, combined with the not-complete revulsion as to using
aggregates as a base for such functionality....

What if we extended aggregates to support a function as an initial
condition which could be called with parameters when initializing the
aggregate?  If you squint at it just right, the current form is that
of a value/constant -- effectively the zero-parameter function.

Here's a gist of what I want to realize:

SELECT (avg())(column_name)
FROM ...

This is a vanilla average.  That's not very interesting since avg only
has one default initial value.  However, at Truviso we have
encountered a real case where we wanted SUM to be initialized to "0"
instead of "NULL".  I had to create a new aggregate with that as an
initial condition, which is fine because we only needed one extra
standard behavior.  But perhaps instead it could have been written
this way:

SELECT (sum(0))(column_name)
FROM ...

That way people could get 'zero' rather than NULL when their query
yields no rows.  You could also imagine some code out there that may
have a running-sum of sorts, and may want to seed SUM to some
non-zero, non-NULL initial value as set by the application.

At that point we may be able to abuse the aggregate infrastructure to
doing what we want in the case of these COPY extensions more easily...

fdr


pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: ALTER TABLE, find_composite_type_dependencies and locking
Next
From: "Kevin Grittner"
Date:
Subject: Re: tsearch parser inefficiency if text includes urls or emails - new version