Re: BUG #3852: Could not create complex aggregate
От | Joe Conway |
---|---|
Тема | Re: BUG #3852: Could not create complex aggregate |
Дата | |
Msg-id | 47823E67.20005@joeconway.com обсуждение исходный текст |
Ответ на | Re: BUG #3852: Could not create complex aggregate (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #3852: Could not create complex aggregate
Re: BUG #3852: Could not create complex aggregate |
Список | 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 по дате отправления: