Скромный вопрос. ORM ругается на то что запрос не корректен, хотя

ровно тот же запрос на sqlite выполнялся без особых вопросов.
Это ORM попусту возникает или в PostgreSQL такой запрос действительно не выполнится?

Текстом показывайте. Но скорее всего да, вряд ли Вы сходу нашли bug в postgres. ;)

Могу со скрина запрос набрать, если так принципиально)

Если Вам не принципиально, чтобы Вам помогали — не набирайте. ;)

вот я хотел выделить текст ошибки, но как мне сделать с вашего скриншота? ))

Есть же слова👌 Можно сказать где именно то на что вы хотели обратить внимание) P.S. По ссылке из ошибки уже ходил P.P.S. ORM - sqlalchemy v1.4.0b3, если это важно

Да вот так же — https://ms-paint-i.de/ (какие-то мы тут несовременные, в самом деле). :)

я указал compiler.py:362, пробовали гуглить по тексту ошибки? она явно относится больше к sqlalchemy чем к постгресу

По тексту ошибки не гуглится, локализация видимо жизнь портит)

Я Вам уже по сути вопроса ответил, нет? Или что-то ещё непонятно?

По-английски это так, если что: "column %s.%s must appear in the GROUP BY clause or be used in an aggregate function"

Больше душевное спасибо, вроде бы нашлось несколько ответов👌

Тем не менее, https://t.me/pgsql/285647 Sqlite сейчас хуже всех распространённых СУБД в плане попыток как-то выполнить абсурдные запросы, к сожалению. Так что на него "равняться" вообще не стоит.

а что можете сказать по поводу H2? довольно распространенно среди разработчиков. для локального тестирования

Честно говоря не ожидал что запрос который в скулайте отрабатывал исправно будет кривым для постгреса

Была некоторая надежда на то что "SQL есть SQL!")

SQLite очень много стандартов не поддерживает или плюет на них. И это сделано специально.

Я про него ничего не знаю / не сталкивался, извините. И насчёт распространённости — хоть даже https://db-engines.com/en/ranking

Оно то так, но некоторые СУБД отступают от стандарта (местами внося свои расширения, но бывают и грубые отступления и вот эта "фишка" с группировкой не по всем полям, которые не обёрнуты агрегатной функцией - пример грубого отступления)

Можете в любой распространённой СУБД его попробовать, если любопытно — так же "свалится" (с подобной ошибкой). Хоть вот тут: https://dbfiddle.uk/

Все СУБД отступают от стандарта, местами нарушая его, по разным причинам. А вот sqlite когда-то содрал это с MySQL "по старой памяти" поддерживает всякое странное. ;)

В общем-то нынешнюю версию запроса можно отправлять фтопку и переписывать заново

Небольшое пояснение: Запрос, по идее, должен выбрать все переписки по user.id, для каждой переписки выбрать последнее сообщение и дополнить его id и name юзера с которым беседа (не того переписки которого выбираются) То есть чтобы исправить это нужно группировку делать не по interlocutor, т.к. это не позволяет СУБД, так?

Если нужна помощь с написанием запросов, лучше показывать \d (или CREATE TABLE со всеми indexes и constraints) каждой относящейся к делу таблицы (лучше работающий пример на каком-то из sqlfiddles); с тестовыми данными и примером результата на этих данных (в виде комментариев или VALUES, неважно). > т.к. это не позволяет СУБД, так? СУБД это вполне позволяет, проблема-то там не в этом была, нет?

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

И каждый, кому захочется Вам помочь и что-то попробовать (какой-то запрос), должен сам написать CREATE TABLE и т.п., которые у Вас уже есть? ;) И это же не всё, о чём я писал...