This may or may not be helpful: txid_current_if_assigned().
Sometimes @@trancount is used to see if the current context is within a transaction - without regard to depth. If that is your case maybe this can help.
SELECT * FROM txid_current_if_assigned();
txid_current_if_assigned
--------------------------
NULL
(1 row)
BEGIN;
BEGIN
CREATE TABLE delete_me (x INTEGER NOT NULL);
CREATE TABLE
SELECT * FROM txid_current_if_assigned();
txid_current_if_assigned
--------------------------
656442
(1 row)
ROLLBACK;
ROLLBACK
SELECT * FROM txid_current_if_assigned();
txid_current_if_assigned
--------------------------
NULL
(1 row)
txid_current_if_assigned
--------------------------
NULL
(1 row)
BEGIN;
BEGIN
CREATE TABLE delete_me (x INTEGER NOT NULL);
CREATE TABLE
SELECT * FROM txid_current_if_assigned();
txid_current_if_assigned
--------------------------
656442
(1 row)
ROLLBACK;
ROLLBACK
SELECT * FROM txid_current_if_assigned();
txid_current_if_assigned
--------------------------
NULL
(1 row)
Note that I had to actually make a modification to get the transaction ID to be assigned. With MSSQL, @@trancount gets set to 1 right away when you open a transaction - without you having to modify anything.
Tom
On Saturday, May 29, 2021, 6:28:47 PM EDT, MichaelDBA <michaeldba@xxxxxxxxxxx> wrote:
This is sooooo funny how this thread has been progressing. The purpose
for TRANCOUNT is for applications to track the state of transactions for
a given connection to the database. TRANCOUNT keeps track of open
transactions and is intented for usage in MSSQL server since
transactions are handled differently there. In PG we don't have this
"stacked" transactions scenario unit PG 11 where we started to support
procedures that can call other procedures and hence we can have a
stacked list of open transactions. But still, TRANCOUNT in PG is
basically useless, so when you convert from MS SQL to PG, just throw the
damn thing away!
Regards,
Michael Vitale
Thomas Kellerer wrote on 5/29/2021 2:15 PM:
> mustafa.pekgoz@xxxxxxxxxxxxxx schrieb am 29.05.2021 um 15:07:
>> I have a procedure where they have used @@TRANCOUNT , is there an
>> equivalent of @@TRANCOUNT in PostgreSQL? (Except Savepoint)
> The equivalent in Postgres is
>
> SELECT 1
>
>
>
>
for TRANCOUNT is for applications to track the state of transactions for
a given connection to the database. TRANCOUNT keeps track of open
transactions and is intented for usage in MSSQL server since
transactions are handled differently there. In PG we don't have this
"stacked" transactions scenario unit PG 11 where we started to support
procedures that can call other procedures and hence we can have a
stacked list of open transactions. But still, TRANCOUNT in PG is
basically useless, so when you convert from MS SQL to PG, just throw the
damn thing away!
Regards,
Michael Vitale
Thomas Kellerer wrote on 5/29/2021 2:15 PM:
> mustafa.pekgoz@xxxxxxxxxxxxxx schrieb am 29.05.2021 um 15:07:
>> I have a procedure where they have used @@TRANCOUNT , is there an
>> equivalent of @@TRANCOUNT in PostgreSQL? (Except Savepoint)
> The equivalent in Postgres is
>
> SELECT 1
>
>
>
>