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

Re: BUG #3852: Could not create complex aggregate

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sokolov Yura <funny(dot)falcon(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #3852: Could not create complex aggregate
Date: 2008-01-07 14:59:51
Message-ID: 47823E67.20005@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Tom Lane wrote:
> "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.
[snip]
> 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.
[snip]
> lookup_agg_function()
> should always invoke enforce_generic_type_consistency(), with this
> argument "true".

This sounds like a reasonable plan to me.

> 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.

I agree, especially since this is the first time anyone has complained.

Did you want me to work on this? I could probably put some time into it 
this coming weekend.

Joe

In response to

Responses

pgsql-hackers by date

Next:From: Usama DarDate: 2008-01-07 15:00:05
Subject: Re: VACUUM FULL out of memory
Previous:From: Usama DarDate: 2008-01-07 14:49:47
Subject: Re: Tuning Postgresql on Windows XP Pro 32 bit

pgsql-bugs by date

Next:From: Stefan KaltenbrunnerDate: 2008-01-07 18:02:51
Subject: Re: BUG #3850: Incompatibility among pg_dump / pg_restore.
Previous:From: Bill MoranDate: 2008-01-07 13:30:37
Subject: Re: BUG #3853: Autovacuum not working

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