Re: Review: listagg aggregate

2010/1/24 David E. Wheeler <david(at)kineticode(dot)com>:
> On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote:
>
>> can I help with it, please. My English is terrible.
>
> Yes, I added a bit in the patch I submitted.
>
>> array user functions are used more time in pg core. The complexity of
>> array functions are much higher, so I don't think we need special
>> file.
>
> Okay. Should have tried it in PL/pgSQL then, perhaps.
>

:) - I'll look on it again.

>> I'll recheck it. I am sure so all parameters should be a text.
>
> Probably shouldn't go into varchar.c then, yes?
>
>> We can, but it isn't good way. Processing of arrays is little bit more
>> expensive then processing plain text. It is reason why listagg is
>> faster, than your custom aggregate. More, the final function could be
>> faster - the content is final.
>
> Understood.
>
>> It normal for aggregate functions. We need more transfn function,
>> because we need two two variant: listagg(col), listagg(col, sep). Our
>> coding guidlines doesn't advice share C functions - but these
>> functions are +/- wrapper for accumStringResult - so there is zero
>> overhead.
>
> Ah, okay, it's because of the second argument. Now I understand.
>
>> I don't think. When we have function, with same parameters, same
>> behave like some Oracle function, then I am strongly prefer Oracle
>> name. I don't see any benefit from different name. It can only confuse
>> developers and add the trable to people who porting applications.
>
> Meh. If the name is terrible, we don't have to use it, and it's easy enough to create an alias in SQL for those who need it.
>

The "list" is common name for this content - it is usual in Microsoft
SQL Server, it is usual in Oracle. Maybe we can vote about the name

Regards
Pavel Stehule

> Best,
>
> David
>
>