2010/1/24 David E. Wheeler <da...@kineticode.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 > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
