Re: array_agg and array_accum (patch)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: array_agg and array_accum (patch)
Date: 2008-11-13 23:12:00
Message-ID: 3517.1226617920@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Jeff Davis wrote:
>> Here's an updated patch for just array_accum() with some simple docs.

> I have committed a "best of Robert Haas and Jeff Davis" array_agg()
> function with standard SQL semantics. I believe this gives the best
> consistency with other aggregate functions for the no-input-rows case.
> If some other behavior is wanted, it is a coalesce() away, as the
> documentation states.

The original reason for doing this work, I think, was to let us
deprecate contrib/intagg, or at least turn it into a thin wrapper
around core-provided functionality. We now have the means to do that
for int_array_aggregate, but what about int_array_enum?

It seems that it would be an easy evening's work to implement unnest(),
at least in the simple form
function unnest(anyarray) returns setof anyelement

without the WITH ORDINALITY syntax proposed by the SQL spec. Then
we could eliminate intagg's C code altogether, and just write it
as a couple of wrapper functions.

Does anyone have an objection to doing that?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Benedek László 2008-11-13 23:31:04 Re: pg_dump roles support
Previous Message Robert Haas 2008-11-13 23:08:24 Re: Simple postgresql.conf wizard