Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'
Дата
Msg-id 28839.1398461182@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'  (Tomas Vondra <tv@fuzzy.cz>)
Ответы Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'  (Tomas Vondra <tv@fuzzy.cz>)
Список pgsql-hackers
Tomas Vondra <tv@fuzzy.cz> writes:
> On 23.4.2014 16:07, Tom Lane wrote:
>> To be concrete: let's add a new boolean parameter with the semantics
>> of "final function takes extra dummy arguments" (default false).
>> There would need to be one for the separate moving-aggregate final
>> function too, of course.

> Do we really need a separate parameter for this? Couldn't this be
> decided simply using the signature of the final function? Either it has
> a single parameter (current behavior), or it has the same parameters as
> the state transition function (new behavior).

The problem is that the CREATE AGGREGATE syntax only specifies the name of
the final function, not its argument list, so you have to make an
assumption about the argument list in order to look up the final function
in the first place.

I did consider the idea of looking for both signatures and using whatever
we find, but that seems fairly dangerous: the same CREATE AGGREGATE
command could give different results depending on what versions of the
final function happen to exist.  This would create an ordering hazard that
pg_dump could not reliably cope with, for example.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Expression indexes ignore typmod of expression
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Expression indexes ignore typmod of expression