Re: Window-functions patch handling of aggregates
От | Hitoshi Harada |
---|---|
Тема | Re: Window-functions patch handling of aggregates |
Дата | |
Msg-id | e08cc0400812250659u45355f55j55e18bbf755b41c9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Window-functions patch handling of aggregates ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
2008/12/25 Pavel Stehule <pavel.stehule@gmail.com>: > 2008/12/25 Hitoshi Harada <umi.tanuki@gmail.com>: >> 2008/12/25 Greg Stark <greg.stark@enterprisedb.com>: >>> Yeah, it seems like adding a flag like iswindowable to aggregate functions >>> is the safest option. >>> >>> It would be nice if it represented an abstract property of the state >>> function or final function rather than just "works with the implementation >>> of window functions". I'm not sure what that property is though - >>> isidempotent? isreentrant? Maybe just a vague isrepeatable? >> >> No, I meant wrinting such like: >> >> Datum >> some_trans_fn(PG_FUNCTION_ARGS) >> { >> if (fcinfo->context && IsA(fcinfo->context, WindowAggState)) >> elog(ERROR, "some_agg does not support window aggregate"); >> >> ... >> } >> >> rather than adding column to catalog. To add flag you must add new >> syntax for CREATE AGGREGATE, which is slightly more painful. >> > > enhancing of CREATE AGGREGATE syntax should be better, it could solve > problem with compatibility. > Most of the aggregates have no problem with this issue and the rest are fixable like array_agg. So adding a column and syntax is too much, I guess. My suggestion of raising error is urgent patch for third party aggregates that are copied from contrib/intagg. But if there is a chance of general approach to call repeatable aggregate other than WindowAgg, that should be considered. Regards, -- Hitoshi Harada
В списке pgsql-hackers по дате отправления: