model что-то вроде расчетов excel-листа. Вещь достаточно специфичная и трудновоспринимаемая в реляционных реалиях, к тому же, не имеет нормальной относительной адресации ячеек, что иногда требует замешивания с аналитическими row_number() over().
Появилась еще в 10г, но на практике крайне редко применяемая. Разве что для замены with-рекурсии, появившейся в более поздней версии (древнеоракловая connect by-рекурсия не позволяет работать с накопительными счетчиками). Функционал model можно процедурно выразить pipelined-функциями, но в оракле переключение plsql-контекста очень дорого и реализация функцией более громоздка, так как требует отдельного создания объектного и табличного типов. Полагаю, что для postgresql реализация функцией будет достаточно эффективной, чтобы не заморачиваться с экзотикой model. Хотя тут тогда хотелось бы иметь возможность применять with-function непосредственно в запросе, то есть без создания хранимки.
Описание model http://docs.oracle.com/database/121/DWHSG/sqlmodel.htm

В оракле 12ц появилась более достойная реализации фича match_recognize, позволяющая оперировать последовательностью упорядоченных данных. Заменяет многовложенные подзапросы с оконными функциями на более лаконичные и формализованные на более подходящем для описания серий данных языке паттернов, накопительных показателей и агрегатов. Типичное применениe - выделение пиков/спадов/подъемов и прочих групп в серии. Такого рода аналитика ближе по духу к реляционным СУБД и потребность в ней возникает почаще modelных inter-row calculations.
Описание http://docs.oracle.com/database/121/DWHSG/pattern.htm
Примеры задач на sql.ru:
Сброс суммы при превышении порога 17674425
Периоды положительного баланса 15515818
Маршрут из точки А в точку Б 15981735

СерджиоБыло бы неплохо использовать подзапросы в CHECKнет смысла в декларативности ограничения, которое зависит от стечения закомиченности данных на какой-то момент.