oh.. thanks

Всем привет!
Коллеги кто то сталкивался с подобной задачей, или знает решение просьба помичь) буду рад любой помощи!
Есть таблица с сообщениями, нужно вывести список сообщений исодя из полученных параметров в виде даты start end ,  для этого использую BETWEEN, проблема в следующем, могу ли я каким то образом. в Postgres проверить если с текущей даты нет результатов к примеру Null то автоматом прошла еще одна проверка с новым диапазоном , например к текущей добавяется + 1 day и так далее пока не найду результат , то есть чтобы Postgres через какую нибудь процедуру понимал если null тогда еще раз выборка

SELECT date_trunc('day', dd):: date, (select message from messages where date>=dd order by date limit 1)
FROM generate_series
       ( '2021-01-01'::timestamp
       , '2021-01-05'::timestamp
       , '1 day'::interval) dd;

должен пройтись по диапазону дат и к каждой дате выбрать сообщение ближайшее к ней. если не будет в эту дату, возьмет за следующий день и так далее

Здравствуйте, спасибо за ответ! Правильно понял исходя из этой даты то есть в этом диапазоне
( '2021-01-01'::timestamp
       , '2021-01-05'::timestamp
       , '1 day'::interval) dd;

а если к примеру 2021-01-01 по 2021-01-02 если null далее он не будет проверять к примеру вот таким образом 2021-01-02 по 2021-01-03

если записи за дату 2021-01-01 не будет - то он найдет ближайшую к ней больше, то есть 01-02, нету, 01-03. там будет null в случае если вообще сообщений позже чем 2021-01-01 нету.

и так для каждой даты

единственный минус что если за 01-02 нет даты, а за 01-03 есть то и в дате 01-02, 01-03 будет лежать одно и тоже сообщение

спасибо огромное )))

а можно как то отфильтровать?

просто получается подобным образом, все равно я буду выдовать не корректный результат с датой

как нибудь можно

ну как бы вы поставили задачу так

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

да все верно ) спасибо большое 😊

Возвращаясь к вопросу целесообразности массивов/nosql и т.д. - смотрю сейчас на очень интересную табличку (настройки пользовательского интерфейса), в которой 70 (!) столбцов и всего одна строка! Причем, как бы данные не изменялись, строка всегда будет одна. Отслеживая запросы в приложении пришел к выводу, что целиком из таблицы никогда ничего не выбирается, только по определенным группам столбцов, столбцы между группами не пересекаются 🤦🏼‍♂️

В идеале, как мне кажется достаточно было бы 3 столбцов id (int), name (varchar), value (json) и раздробить всю эту кашу группами по строкам, но какая-то извращенная логика подсказала архитектору всего этого г..а, что нужно так и никак иначе

Почти всегда это не следствие планирования, а просто кривая так вывезла в процессе эксплуатации и доделок.
И в команде ни у кого не хватает твёрдости взять и исправить.

и тут даже не в твердости дело, просто надо ответить на вопросы
- кому от этого сейчас плохо
- кому станет лучше, если все переделать

и, конечно же,
- во что выльется переделка, если посчитать все косты