Dmitry Yemanov wrote:

>Doable. Some RDBMS offer this feature. In fact, it's already implemented in
>Yaffil and I think we could easily backport this code into FB3. This new
>aggregate function is LIST (<value>, <separator>).
>
>

Sounds good. Glad to hear that this seems feasible to you.

>>>1) What is the output datatype for the SUM (this needs to be known at
>>>prepare time)?
>>>
>>>
>
>[VAR]CHAR (MAX_COLUMN_SIZE)
>
>

Would it handle numeric fields as well or only [var]chars? I guess it
could implicity cast everything to a varchar (the same way the ordinary
concatenation operator works.

>>How about an array? This would also make the individual elements easier
>>to access, so that they can then be manipulated in any way necessary,
>>not necessarily by concatenation.
>>
>>
>
>No arrays, please. Don't forget they're implemented only partially and e.g.
>not available in PSQL. To be honest, <flame on> I would prefer them to
>become deprecated instead of explaining people why arrays cannot be used
>here and are buggy there </flame>.
>
>

Ok. Pity, as it did seem like a better way of doing it. But I guess
specifying the operator is good enough.

>>>2) I do this on 1.000 records with a average of 500 characters per
>>>
>>>
>record?
>
>You'll get a runtime error (concatenation overflow). When we raise the row
>size to be represented with a longword, this issue will go away.
>
>
>
>>You could. It would probably still be faster than fetching 1000 records
>>or 500 characters each, and doing it all on the client side.
>>
>>
>
>The engine will still fetching all rows internally, so the only benefit you
>get is lack of network transmission.
>
>
>

Ok. But still, it would in some cases avoid an additionnal query, which
would therefore make it a both simpler and faster approch.

>>But I think this would mostly be useful in cases where there are a small
>>number of records being grouped together, because it would in such cases
>>be a simple alternative to having a separate query for getting this
>>information.
>>
>>
>
>I'm not a great supporter of this feature, but I'm not going to object
>either.
>
>

Great!

Thanks!
Jonathan Neve.


[Non-text portions of this message have been removed]