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.
> 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.
> 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.
In response to
pgsql-hackers by date
|Next:||From: Usama Dar||Date: 2008-01-07 15:00:05|
|Subject: Re: VACUUM FULL out of memory|
|Previous:||From: Usama Dar||Date: 2008-01-07 14:49:47|
|Subject: Re: Tuning Postgresql on Windows XP Pro 32 bit|
pgsql-bugs by date
|Next:||From: Stefan Kaltenbrunner||Date: 2008-01-07 18:02:51|
|Subject: Re: BUG #3850: Incompatibility among pg_dump / pg_restore.|
|Previous:||From: Bill Moran||Date: 2008-01-07 13:30:37|
|Subject: Re: BUG #3853: Autovacuum not working|