Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
Всем доброго времени суток. Есть PG 8.0.3, на котором запрос вида (про то, что нужно использовать where говорить не стоит, мой пример - упрощение запроса, в котором where не прокатит) select id from <table_name> having id>0 работает на ура. Т.е. выдает все записи c id>0 Есть PG 8.1.2, в котором на этот же запрос выдается ERROR: column "<table_name>.id" must appear in the GROUP BY clause or be used in an aggregate function Вроде того, что если пишешь having, значит должен использовать и group by (или какую-то агрегирующую функцию). Но почему работает в первом случае? Может кто-нибудь просвятить в тонкостях работы having в данном случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2006, 14:54 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
думаю это был баг :) его исправили в 8.0.4 Код: plaintext 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. 38. 39. 40. 41. 42. 43. 44. 45. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2006, 20:07 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
ошибся малость ZemA Код: plaintext 1. 2. 3. должно быть так Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2006, 20:21 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
SOmniНо почему работает в первом случае? Может кто-нибудь просвятить в тонкостях работы having в данном случае? ZemAдумаю это был баг :) его исправили в 8.0.4Это совершенно точно был баг. Причем не просто баг, а очень большой БАГ. Ведь в ANSI-SQL весьма неоднозначно сказано - для фильтрации исходных данных при формировании результирующего датасета используется предложение WHERE, для ДОПОЛНИТЕЛЬНОЙ фильтрации результата работы агрегирующего запроса используется предложение HAVING. Без GROUP BY не может быть и HAVING. Так что, сейчас в этом плане у PostgreSQL все в полном порядке - полное соответствие ANSI-стандарту :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 06:04 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
Ну хорошо. Это был баг. На самом деле запрос выглядит так: select id, id_parent, _level_ from <table_name> connect by prior id=id_parent start with id=1 having _level_<2 Т.е. я выбирал все записи по иерархии уровня вложенности < 2 Куда тут можно впихнуть where я не знаю А теперь так оно не работает и приходится делать что-то вроде: select * from (select id, id_parent, _level_ from <table_name> connect by prior id=id_parent start with id=1) as sub where _level_ < 2 Есть более изящное решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 09:55 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
Маленькое пояснение: _level_ - не поле в <table_name> - оно формируется connect_by-ем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 10:07 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
SOmniНу хорошо. Это был баг. На самом деле запрос выглядит так: select id, id_parent, _level_ from <table_name> connect by prior id=id_parent start with id=1 having _level_<2 Т.е. я выбирал все записи по иерархии уровня вложенности < 2 Куда тут можно впихнуть where я не знаю А теперь так оно не работает и приходится делать что-то вроде: select * from (select id, id_parent, _level_ from <table_name> connect by prior id=id_parent start with id=1) as sub where _level_ < 2 Есть более изящное решение?Грубо говоря ты выбирал все корни? В данном конкретном слечае - запись с ID = 1. Так зачем нужно было городить иерархический запрос для этих целей? Не знаю как в PostgreSQL, но в Oracle вот такой запрос отрабатывает на ура: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 10:27 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
"2" - не принципиально. Пусть будет 10. Всё равно, в PG where вставить в это место нельзя, получишь ERROR: column "_level_" does not exist ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 10:31 |
|
||
|
Различное поведение запроса в зависимости от версии PG
|
|||
|---|---|---|---|
|
#18+
Ну попробуй ещё вот так: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 10:38 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=319&tid=2006344]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 382ms |

| 0 / 0 |
