Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID - Mailing list pgsql-hackers

From Kirk Wolak
Subject Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Date
Msg-id CACLU5mTrL2MoQhx0HgGWKdTFr7_ag=Siw-VPm1B+q5e_B3fa+g@mail.gmail.com
Whole thread Raw
In response to possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


On Tue, Feb 7, 2023 at 2:49 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi

I have a question about the possibility of simply getting the name of the currently executed function. The reason for this request is simplification of writing debug messages.

GET DIAGNOSTICS _oid = PG_ROUTINE_OID;
RAISE NOTICE '... % ... %', _oid, _oid::regproc::text;

The advantage of this dynamic access to function name is always valid value not sensitive to some renaming or moving between schemas.

I am able to separate a name from context, but it can be harder to write this separation really robustly. It can be very easy to enhance the GET DIAGNOSTICS statement to return the oid of currently executed function. 

Do you think it can be useful feature?

I was hoping it could be a CONSTANT like TG_OP (so the extra GET DIAGNOSTICS wasn't invoked, but I have no idea the weight of that CODE CHANGE)

Regardless, this concept is what we are looking for.  We prefer to leave some debugging scaffolding in our DB Procedures, but disable it by default.
We are looking for a way to add something like this as a filter on the level of output.

Our Current USE CASE is
  CALL LOGGING('Msg');  -- And by default nothing happens, unless we set some session variables appropriately

We are looking for
  CALL LOGGING('Msg', __PG_ROUTINE_OID );  -- Now we can enable logging by the routine we are interested in!

The LOGGING routine currently checks a session variable to see if logging is EVEN Desired, if not it exits (eg PRODUCTION).

Now we can add a single line check, if p_funcoid  is IN my list of routines I am debugging, send the output.

I will gladly work on the documentation side to help this happen!

+10


 

The implementation should be trivial.

Comments, notes?

Regards

Pavel


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PATCH: Using BRIN indexes for sorted output
Next
From: Thomas Munro
Date:
Subject: Re: Too coarse predicate locks granularity for B+ tree indexes