Re: BUG #3852: Could not create complex aggregate - Mailing list pgsql-bugs

From Joe Conway
Subject Re: BUG #3852: Could not create complex aggregate
Date
Msg-id 47823E67.20005@joeconway.com
Whole thread Raw
In response to Re: BUG #3852: Could not create complex aggregate  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #3852: Could not create complex aggregate  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: BUG #3852: Could not create complex aggregate  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane wrote:
> "Sokolov Yura" <funny.falcon@gmail.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


pgsql-bugs by date:

Previous
From: Bill Moran
Date:
Subject: Re: BUG #3853: Autovacuum not working
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: BUG #3850: Incompatibility among pg_dump / pg_restore.