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 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
needit.
Best,
David
