|
MERGE with DELETE option
|
|||
---|---|---|---|
#18+
Есть задача переписать запрос из базы которая поддерживает сабдж в постгрес который его не поддерживает. Если бы без DELETE можно было бы использовать INSERT ON CONFLICT, но тут так переписал, работает, теперь бы понять почему и как, в других базах так не должно работать, куски в WITH не связаны вызовами. но куски последовательно вызываются и дают нужный результат причем только в такой последовательности работает Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2020, 12:49 |
|
MERGE with DELETE option
|
|||
---|---|---|---|
#18+
Поправьте если не прав, на выходе скрипта получите вставку двух строк (2,24,'CURR'), (4,42,'CURR') в myTab2 и все. Не понятно: - зачем truncate для только что созданных таблиц - блок upd вроде ни чего не делает, поскольку сравнение идет по pid удаленной строки. Т.е. в del строку с таким pid удалили и пытаетесь её же обновить в upd. Если не прав, покажите какой результат на выходе получаете. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2020, 11:38 |
|
MERGE with DELETE option
|
|||
---|---|---|---|
#18+
Guzya Поправьте если не прав, на выходе скрипта получите вставку двух строк (2,24,'CURR'), (4,42,'CURR') в myTab2 и все. Не понятно: - зачем truncate для только что созданных таблиц - блок upd вроде ни чего не делает, поскольку сравнение идет по pid удаленной строки. Т.е. в del строку с таким pid удалили и пытаетесь её же обновить в upd. Если не прав, покажите какой результат на выходе получаете. в этом и проблема/успех, что все куски отрабатывают, даже если не вызываются явно транкейт просто для удобства отладки чтобы не дропать исходно Код: sql 1. 2. 3. 4.
результат удалили ID=2 обновили ID=3 вставили ID=4 при этом учлось что ID=2 и 3 было в первоначальной таблице Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2020, 15:17 |
|
MERGE with DELETE option
|
|||
---|---|---|---|
#18+
7.8.2. Изменение данных в WITH Вложенные операторы в WITH выполняются одновременно друг с другом и с основным запросом. Таким образом, порядок, в котором операторы в WITH будут фактически изменять данные, непредсказуем. Все эти операторы выполняются с одним снимком данных (см. Главу 13), так что они не могут «видеть», как каждый из них меняет целевые таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2020, 17:37 |
|
MERGE with DELETE option
|
|||
---|---|---|---|
#18+
из-за того что так подобрались данные insert into myTab values(3, 0,'OBS' ); принял работу скрипта за правильную, а то у меня уже мозг закипать стал, ну как так то? исправил исходные данные insert into myTab values(3, 1,'OBS' ); Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
теперь видно, что апдейт проходит 15+1=16 Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2020, 17:58 |
|
MERGE with DELETE option
|
|||
---|---|---|---|
#18+
Guzya 7.8.2. Изменение данных в WITH Вложенные операторы в WITH выполняются одновременно друг с другом и с основным запросом. Таким образом, порядок, в котором операторы в WITH будут фактически изменять данные, непредсказуем. Все эти операторы выполняются с одним снимком данных (см. Главу 13), так что они не могут «видеть», как каждый из них меняет целевые таблицы. именно поэтому используется явно RETURNING ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2020, 18:01 |
|
|
start [/forum/topic.php?fid=53&msg=39947956&tid=1994722]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 285ms |
total: | 420ms |
0 / 0 |