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'
|
Список | 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 по дате отправления: