Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

Поиск
Список
Период
Сортировка
От Kirk Wolak
Тема Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Дата
Msg-id CACLU5mTrL2MoQhx0HgGWKdTFr7_ag=Siw-VPm1B+q5e_B3fa+g@mail.gmail.com
обсуждение исходный текст
Ответ на possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: Using BRIN indexes for sorted output
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Too coarse predicate locks granularity for B+ tree indexes