Re: [HACKERS] array_accum aggregate
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] array_accum aggregate |
Дата | |
Msg-id | 16466.1160755322@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] array_accum aggregate (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] array_accum aggregate
|
Список | pgsql-patches |
Stephen Frost <sfrost@snowman.net> writes: >> That's not really the flavor of solution I'd like to have. Ideally, >> it'd actually *work* to write >> my_ffunc(my_sfunc(my_sfunc(null, 1), 2)) > In general I like this idea but there are some complications, the main > one being where would the memory be allocated? In the agg context if called with that context, else CurrentMemoryContext will do fine. > The other issue is, in the above scenario > is it acceptable to modify the result of my_sfunc(null, 1) in the ,2 > call? Yes, because the only place a nonnull value of the type could have come from is a my_sfunc call; since it's a pseudotype, we don't allow it on disk. (We might also need a hack to prevent the type from being used as a record-type component ... not sure if that comes for free with being a pseudotype currently.) > As for a type for each such aggregate, that seems reasonable to me, > honestly. The ugly part is that we'd still need a way for the planner to recognize this class of types. > Additionally, we'd have to be > able to mark the types as being polymorhpic along the same lines as > anyelement/anyarray. What for? regards, tom lane
В списке pgsql-patches по дате отправления: