Как сделать вот такой SQL запрос

имхо никак. потому что задача СУБД - хранение и поиск данных, а не их приобразования.

Но ведь есть всякие count и sum... В моем примере нужна функция по типу sum только для конкатенации

потому что задача СУБД - хранение и поиск данных, а не их приобразования.

Гг. Тогда bdb хватило бы всем с головой.

Постгрес какой версии?

Начиная с 9.0 есть string_agg. Начиная с 8.4 array_agg/array_to_string.

ты будешь удивлён.. man zodb

если ид очень маленькие то что-то потипу sum(pow(2,некий ид))

ты будешь удивлён.. man zodb

И чем же меня должна удивить тормозная недобд?

string_agg то что нужно, спс. только там еще тип ид нужно приводить к text.

Пиши процедуру, которая на входе берёт список и склеивает его.

http://sqlfiddle.com/#!15/704ee/5

Не знаю как в постгресе, но в оракле приходилось писать функцию, которая конкатенирует информацию по id и выводит ее в result - вот пример:

   cursor get_diag_pacient is
-- твой запрос для хранения в курсоре
	OPEN get_diag_pacient; 
  
  for i in 1.. get_diag_pacient%rowcount loop

   FETCH get_diag_pacient INTO v_diag;	
          res:= res || ' ' || v_diag;
          
         end loop;
  
  
	CLOSE get_diag_pacient; 
return (trim(res));
end;

LISTAGG? БД не стоят на месте, ваши древние велосипеды, как правило, становятся не нужными с очередным релизом.

в контрибах есть агрегатные функции чтобы ты смог группировать по имени и слеплять иды в массив, кажется

как постгре не знаю, у нас достаточно тривиально

SELECT Name,LIST(ID)
FROM SomeTable
GROUP BY Name

Если агрегатной LIST нет в движке, то народ как то выкручивался - вот http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=357553&ms...

у нас достаточно тривиально

Где у нас?)

как постгре не знаю

Ответ уже давно написали. string_agg().

select name, твоя_функция_конкатенации(id) from your_table group by name

Какой то парад скоро-дрочеров устроили...

он спросил, я ответил, я только в упор не понимаю зачем это тс'у (то есть тебе)

он спросил, я ответил,

Очень странно смотрится когда в 4 посте дают ответ а потом еще 10 постов «Не знаю как в постгресе но...»

я только в упор не понимаю зачем это тс'у (то есть тебе)

Для работы естественно.) Только там была задача намного сложнее, просто выделил интересующий меня вопрос в маленькую придуманную задачу.

Для работы естественно.)

ну это понятно. Ну опиши задачу, хотя бы кратко, я а то в голову не идет зачем таким образом на стороне СУБД данные представлять.

Ну опиши задачу, хотя бы кратко, я а то в голову не идет зачем таким образом на стороне СУБД данные представлять.

Есть таблица с некими событиями ид события, время начала, время окончания, куча всяких данных. Есть вторая таблица в которой идет привязаны адреса домов к ид событию. Нужно было вывести количество событий за определенный пириуд для каждого адреса + посчитать общую длительность этих событий + ид самих событий через запятую. Джойним таблицы, делаем group by по адресу, общее время вычисляем и складываем через sum, количество событий через count, список идентификаторов, как выяснилось, через string_agg.

LISTAGG

Она появилась то ли в 10, то ли в 11-й версии. А в старых приходится выкручиваться самописными велосипедами.

вот блин, генератор отчетов чтоле прикрути для такого.

вот блин, генератор отчетов чтоле прикрути для такого.

Зачем если это делается одним запросом к базе? К тому же это не совсем отчет, скорее статистика.

А в старых приходится выкручиваться самописными велосипедами.

Пользователи копробаз должны страдать, да.

Где у нас?)

http://www.intersystems.com/our-products/cache/cache-overview/

http://www.intersystems.com/our-products/cache/cache-overview/

Я вообще то имел в виду что когда пишешь подобные посты неплохо бы указать какая бд.

Это и есть БД, если чо

приобразования

приобразование - это то, что ты получил вместо образования