Комментарии 15
update test set id = t2.id + 1 from test t2;

Так и не понял чего вы хотели добиться.

действительно увеличит значение столбца id на 1.

update test set id=id+1;

Если не это, то:
update test
set id=subquery.field+1
from (select at.my,at.precious,at.fields,rtt.test_id
from another_table as at
left join relation_table rtt
on rtt.at_at=at.id) as subquery
where test.id=subquery.test_id


И тут уж развлекайтесь как душе угодно.

В Mail.ru Group много разных команд

А еще ну очень плохая репутация в игровом мире.
Да и про Mail.Агент до сих пор с ужасом многие вспоминают.
Ну и ЦРПТ тоже наверняка разработка выходцев из Mail.ru Group.
Короче, извините, не убедили)

Зы а куда спрятался sql с нормальным форматированием из кода? 8(
Если не это, то:
update test
set id=subquery.field+1
from (select at.my,at.precious,at.fields,rtt.test_id
from another_table as at
left join relation_table rtt
on rtt.at_at=at.id) as subquery
where test.id=subquery.test_id

А в чем преимущество использования подзапроса? Если бы это хотя-бы позволяло написать update, который одновременно работает и на PostgreSQL и на MySQL, но нет. Если в обоих СУБД синтаксис позволяет написать более компактно без подзапроса, то зачем писать подзапрос? Чтобы проверить сработает ли оптимизатор и раскроет подзапрос или начнет его материализовывать? Весь мой опыт работы с MySQL говорит о том, что так делать не стоит.
Преимущество перед чем? Если у вас ложный набор данных то вот вам вариант, и негативных моментов у него можно сказать что нет.

PostgreSQL и на MySQL

Зачем, кстати? Есть PG — пользуйтесь
то вот вам вариант, и негативных моментов у него можно сказать что нет

Два момента я уже назвал выше.
Зачем, кстати? Есть PG — пользуйтесь

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

Совместимость с MySQL меня лично не волнует от слова совсем, второго момента не увидел. К тому же мы не знаем какие у автора были сложности.

Изначально использовался MySQL, проект переводился на PostgreSQL, в переходный период необходимо было поддерживать работу с двумя СУБД

Ну это врядли. Если только вы PG используете процентов на 10.
Тут скорее проблема в том, что у Postgres довольно странное поведение from в update.
Как бы оно не падает как бы результат update test t1 set t.id = t2+1 from test t2 ну по сути должен упасть, но он не падает. А надо типа так test t1 set t.id = t2+1 from test t2 on t1.id = t2.id при условии, что столбец id уникален. Поэтому лучше подзапросом делать. Тогда будет и в MySql нормально работать. Как вариант коррелрующий подзапрос на каждый столбцец, по идее должно везде работать.
Насчет странного лично у меня нет такого ощущения, давно с пг работаю, хотя пришел из Mysql. Надо будет поиграться понять.

С другой стороны я считаю именно поведение mysql странным почти везде и всюду.
НЛО прилетело и опубликовало эту надпись здесь
на сайтике — вакансии без указания зп. Как серпом по яйцам.

Потому что под одной вакансией фактически скрывается несколько?
Чем бы вам помогло указание в вакансии «от Х до 5*Х денег»?
Запросы были нужны в синтаксисе MySQL и PostgreSQL

Подобный запрос в синтаксисе T-SQL

Непонятно, откуда T-SQL появился. Может, речь о MSSQL, не от MySQL?
Запросы были нужны именно для MySQL и PostgreSQL. Но PostgreSQL и MS SQL имеют разное представление о том, как связаны таблицы в UPDATE и FROM. Программист, который писал запрос имел опыт работы с MS SQL, что и стало, по всей видимости, изначальной причиной ошибки.
Так кто на ком стоял?
Программист умел в MSSQL (T-SQL), написал запрос update t set… from t, как умел в MSSQL, в mySQL это сработало, в PostgreSQL нет?
Он написал по аналогии для PostgreSQL. Для MySQL был другой запрос, т.к. там еще более другой синтаксис и с ним проблем не было.

но зачем его? не было других, кто знает PgSQL/MySQL? А, даже если и не было, неужто не догадывались, что после него надо не только 7 раз отмерить, но и перед отрезом ещё раз пару раз отрезать на черновом материале

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.