Re: Runtime parameter holding is_in_transaction state

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

In response to

Browse pgsql-novice by date

  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?