Skip site navigation (1) Skip section navigation (2)

Re: BUG #3852: Could not create complex aggregate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Sokolov Yura" <funny(dot)falcon(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: BUG #3852: Could not create complex aggregate
Date: 2008-01-06 19:44:47
Message-ID: 24604.1199648687@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
"Sokolov Yura" <funny(dot)falcon(at)gmail(dot)com> writes:
> create or replace function add_group(grp anyarray, ad anyelement, size int4)
> returns anyarray
> language plpgsql
> ...

> create aggregate build_group(anyelement, int4) (
>   SFUNC= add_group,
>   STYPE = anyarray
> );

> ERROR:  argument declared "anyarray" is not an array but type anyarray

After chewing on this for awhile, it seems to me that pg_aggregate.c
is using enforce_generic_type_consistency() in a rather fundamentally
different way than it's being used anywhere else.  Everywhere else,
the "actual" argument types are expected to be real (not polymorphic)
types and enforce_generic_type_consistency() is expected to derive a
real result type.  But in pg_aggregate.c, the "actual" argument types
are the declared input and transition types of the aggregate function,
which could be polymorphic, and it is okay to hand back a polymorphic
result type if there's not enough information yet.

I think we could make enforce_generic_type_consistency() clearer by
adding an additional argument "bool allow_poly" which specifies
whether polymorphic "actual" argument and result types are allowed.
(Or maybe split it into two functions, although I think there'd be a lot
of code duplication.)  In this case it would allow ANYARRAY as the
"actual" argument type matching an ANYARRAY parameter, similarly for
ANYELEMENT, ANYENUM, etc, and it would hand back ANYARRAY or ANYELEMENT
if the result type couldn't be determined yet.  lookup_agg_function()
should always invoke enforce_generic_type_consistency(), with this
argument "true".

Although this problem really goes quite far back, I think it's probably
not interesting to back-patch further than 8.2, because AFAICS the
interesting cases involve aggregates with more than one argument.

Thoughts?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-01-07 01:20:10
Subject: Re: OUTER JOIN performance regression remains in 8.3beta4
Previous:From: Hannes DorbathDate: 2008-01-06 19:42:00
Subject: Index trouble with 8.3b4

pgsql-bugs by date

Next:From: Christopher Brian L. JuradoDate: 2008-01-07 05:44:02
Subject: BUG #3853: Autovacuum not working
Previous:From: Sokolov YuraDate: 2008-01-06 08:57:03
Subject: BUG #3852: Could not create complex aggregate

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group