Subject | Re: [Firebird-Architect] Aggregation by concatenation |
---|---|
Author | Dmitry Yemanov |
Post date | 2004-10-28T06:17:45Z |
"Jonathan Neve" <jonathan@...> wrote:
Yaffil and I think we could easily backport this code into FB3. This new
aggregate function is LIST (<value>, <separator>).
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>.
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.
get is lack of network transmission.
either.
Dmitry
>Doable. Some RDBMS offer this feature. In fact, it's already implemented in
> >>I had an idea of a new feature which I think could be useful, please
> >>tell me what you think. Currently, it's possible to aggregate a column
> >>as a sum, an average, an minimum or a maximum. It would be useful, in
> >>certain cirsumstances, to be able to aggregate a column by concatenating
> >>all the values, or perhaps by putting them all into an array.
Yaffil and I think we could easily backport this code into FB3. This new
aggregate function is LIST (<value>, <separator>).
> > There are many problems with this.Not so many, I think ;-)
> > 1) What is the output datatype for the SUM (this needs to be known at[VAR]CHAR (MAX_COLUMN_SIZE)
> > prepare time)?
> How about an array? This would also make the individual elements easierNo arrays, please. Don't forget they're implemented only partially and e.g.
> to access, so that they can then be manipulated in any way necessary,
> not necessarily by concatenation.
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>.
> >2) I do this on 1.000 records with a average of 500 characters perrecord?
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 recordsThe engine will still fetching all rows internally, so the only benefit you
> or 500 characters each, and doing it all on the client side.
get is lack of network transmission.
> But I think this would mostly be useful in cases where there are a smallI'm not a great supporter of this feature, but I'm not going to object
> 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.
either.
Dmitry