|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
скорее придумано, но тем не менее. Непонятно, зачем в pg так обрабатывается факт неоткрытия курсора. Неоткрытый курсор нельзя присвоить и передать дальше по цепочке - ок. Но зачем на него ругаться так-то: ERROR: query has no destination for result data HINT: If you want to discard the results of a SELECT, use PERFORM instead. ? Ситуация: Код: 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. 26. 27. 28. 29. 30.
тут все в порядке, и код select * from myfunc_someserver(111); возвращает положенные ему данные из нужных таблиц. Далее в результате ребилда отваливается строчка: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Все компилится, но при этом Код: sql 1. 2. 3. 4.
1) сообщение совсем не о том, что на самом деле 2) самое интересное, что в этом логе напрочь отсутствует INTO-секция, что наводит на мысли о всяком нехорошем типа "на БД совсем не то, что в исходниках, кто-то залез в БД и накатил фигню" и проч. собственно, ЗАЧЕМ pg ругается на неоткрытый курсор ТАК? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 13:08 |
|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
HawkmoonДалее в результате ребилда отваливается строчка: Почему она отваливается? У вас нет курсора. Вы просто пытаетесь сделать select никуда. На это plpgsql и обижается. См. CONTEXT - жалуется строго на dbcommon. HawkmoonВсе компилится Если create function сказал "ок" - это значит только и только то, что функция зарегистрирована. Компилировать сейчас её даже не пытаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 18:47 |
|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
MelkijHawkmoonДалее в результате ребилда отваливается строчка: Почему она отваливается? У вас нет курсора. Вы просто пытаетесь сделать select никуда. На это plpgsql и обижается. См. CONTEXT - жалуется строго на dbcommon. HawkmoonВсе компилится Если create function сказал "ок" - это значит только и только то, что функция зарегистрирована. Компилировать сейчас её даже не пытаются. У вас нет курсора. - согласен. Но у меня есть переменная типа refcursor . И я хочу передать ей ошибочно (что к делу не относится) неоткрытый результат. В оракле к такой переменной: VARIABLE O_RC VARCHAR2; VARIABLE O_ERR VARCHAR2; variable o_rs REFCURSOR; EXEC PKG_functional_someserver.sp_myfunc (:O_RC, :O_ERR, 101, 1, :o_rs); PRINT O_RC PRINT O_ERR PRINT O_RS а) можно обратиться б) можно присвоить одно к другому в) можно вывести-вычитать курсор (получив ожидаемое "ничего") безо всяких ORA-ошибок. В pg позиция "нет курсора - нет переменной"? Тогда давайте и выборку из bytea в declare foo bytea гробить, если откуда выбирается - null. Логично же. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 11:24 |
|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
"логично" в том смысле, что в bytea также есть отдельные тоаст-хранилища и прочая лабутень, которая пользователя, обращающегося к БД извне, не интересует. Почему bytea вида null нормально присваивается переменной bytea, а попытка запихать неоткрытое в refcursor приводит не к NULL (я бы понял), не к понятной ошибке, а к "query has no destination for result data" ??? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 11:28 |
|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
HawkmoonУ вас нет курсора. - согласен. Но у меня есть переменная типа refcursor . Так где вы к ней обращаетесь? plpgsql должен сам угадать, что вы хотите этот select вникуда использовать для курсора? Нет, будьте добры это попросить явно. Ещё раз: почему у вас вдруг отваливается строчка? Курсор не курсор не имеет абсолютно никакого значения. Во втором листинге у вас есть в тексте plpgsql хранимки есть select * from pg_user; ничего не указывающий что делать с результатом этого select. plpgsql не может делать select вникуда. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 11:41 |
|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
Melkij plpgsql не может делать select вникуда. Блин. То есть ругань идет не на то, что select t.o_rc, t.o_err, t.o_rs from myfunc_dbcommon(i_myparam) t без слова INTO, а на то, что select * from pg_user; со звездочкой и без слова into? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 12:10 |
|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
Hawkmoonа на то, что select * from pg_user; со звездочкой и без слова into? Здёздочка без разницы. Главное что есть select, а куда его результат девать - не написано. Но да, ошибка именно отсюда. MelkijСм. CONTEXT - жалуется строго на dbcommon. в CONTEXT stacktrace. Ошибка времени разбора текста функции myfunc_dbcommon, вызванной запросом с таким-то текстом. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 12:21 |
|
Почему pg не позволяет возвратить курсор?
|
|||
---|---|---|---|
#18+
Melkij, спасибо бол. Стал ближе к пониманию. При попытке воспроизведения на Oracle и комментарии open o_rs тот сразу отругался на "где into, билли? Нам нужны into" А PG непонятно, и детектируемое место, SQL statement, оказывается , указывает на уровень выше . еще раз спс. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 12:38 |
|
|
start [/forum/topic.php?fid=53&msg=39839865&tid=1995106]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 268ms |
total: | 405ms |
0 / 0 |