Re: Runtime parameter holding is_in_transaction state
От | Sergey Samokhin |
---|---|
Тема | Re: Runtime parameter holding is_in_transaction state |
Дата | |
Msg-id | e42595410909060938o3f79530ct33354e5c8b36f0bf@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Runtime parameter holding is_in_transaction state (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-novice |
Hello. > Maybe you should explain what it is you want to accomplish. Thanks for your answer, Tom! It caused me to start looking for another solution rather than looking for such a variable. The original purpose of asking the question was to find a way to detect that a transaction passed to my server as one big string has failed: // This transaction will never succeed because there is an UPDATE of non existing table // To gracefully get things back I should detect the failure and do ROLLBACK "BEGIN; UPDATE non_existing_table SET foo = 42; <skipped> ; COMMIT;" One way to detect that would be to check if we are still in transaction by SHOW'ing some variable. It seemed like what I should try, because every faulty query leaves its transaction opened. In any way, this solution is much more expensive than conventional traversing the list of results which my driver returns for each complex query. Now when I've chosen a way to check if such a complex query (containing several SQL-commands) failed, I no longer want such a parameter to exist in PG. -- Sergey Samokhin
В списке pgsql-novice по дате отправления: