From: | Sergey Samokhin <prikrutil(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Runtime parameter holding is_in_transaction state |
Date: | 2009-09-06 16:38:19 |
Message-ID: | e42595410909060938o3f79530ct33354e5c8b36f0bf@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jignesh Shah | 2009-09-07 09:33:09 | require some suggestion to write trigger function |
Previous Message | Joshua Tolley | 2009-09-05 03:22:22 | Re: Where to report a bug? |