Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Kirk Wolak <wolakk(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Date: 2023-03-27 06:29:29
Message-ID: CAFj8pRD6ti-bsYH_tObUNznZ_kiPcvDnty0oLW5j2MoGnODoFQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

po 27. 3. 2023 v 5:36 odesílatel Kirk Wolak <wolakk(at)gmail(dot)com> napsal:

> On Sun, Mar 26, 2023 at 5:37 PM Kirk Wolak <wolakk(at)gmail(dot)com> wrote:
>
>> On Wed, Feb 8, 2023 at 10:56 AM Kirk Wolak <wolakk(at)gmail(dot)com> wrote:
>>
>>> On Wed, Feb 8, 2023 at 3:08 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>>> wrote:
>>>
>>>> hi
>>>>
>>>> st 8. 2. 2023 v 7:33 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)com>
>>>> napsal:
>>>>
>>>>> On Tue, Feb 07, 2023 at 08:48:22PM +0100, Pavel Stehule wrote:
>>>>> >
>>>>> > GET DIAGNOSTICS _oid = PG_ROUTINE_OID;
>>>>> > RAISE NOTICE '... % ... %', _oid, _oid::regproc::text;
>>>>> >
>>>>> > Do you think it can be useful feature?
>>>>>
>>>>> +1, it would have been quite handy in a few of my projects.
>>>>>
>>>>
>>>> it can looks like that
>>>>
>>>> create or replace function foo(a int)
>>>> returns int as $$
>>>> declare s text; n text; o oid;
>>>> begin
>>>> get diagnostics s = pg_current_routine_signature,
>>>> n = pg_current_routine_name,
>>>> o = pg_current_routine_oid;
>>>> raise notice 'sign:%, name:%, oid:%', s, n, o;
>>>> return a;
>>>> end;
>>>> $$ language plpgsql;
>>>> CREATE FUNCTION
>>>> (2023-02-08 09:04:03) postgres=# select foo(10);
>>>> NOTICE: sign:foo(integer), name:foo, oid:16392
>>>> ┌─────┐
>>>> │ foo │
>>>> ╞═════╡
>>>> │ 10 │
>>>> └─────┘
>>>> (1 row)
>>>>
>>>> The name - pg_routine_oid can be confusing, because there is not clean
>>>> if it is oid of currently executed routine or routine from top of exception
>>>>
>>>> Regards
>>>>
>>>> Pavel
>>>>
>>>
>>> I agree that the name changed to pg_current_routine_... makes the most
>>> sense, great call...
>>>
>>> +1
>>>
>>
>> Okay, I reviewed this. I tested it (allocating too small of
>> varchar's for values, various "signature types"),
>> and also a performance test... Wow, on my VM, 10,000 Calls in a loop was
>> 2-4ms...
>>
>> The names are clear. Again, I tested with various options, and including
>> ROW_COUNT, or not.
>>
>> This functions PERFECTLY.... Except there are no documentation changes.
>> Because of that, I set it to Waiting on Author.
>> Which might be unfair, because I could take a stab at doing the
>> documentation (but docs are not compiling on my setup yet).
>>
>> The documentation changes are simple enough.
>> If I can get the docs compiled on my rig, I will see if I can make the
>> changes, and post an updated patch,
>> that contains both...
>>
>> But I don't want to be stepping on toes, or having it look like I am
>> taking credit.
>>
>> Regards - Kirk
>>
>
> Okay, I have modified the documentation and made sure it compiles. They
> were simple enough changes.
> I am attaching this updated patch.
>
> I have marked the item Ready for Commiter...
>

Thank you for doc and for review

Regards

Pavel

>
> Thanks for your patience. I now have a workable hacking environment!
>
> Regards - Kirk
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-03-27 06:32:47 Re: refactoring relation extension and BufferAlloc(), faster COPY
Previous Message Bharath Rupireddy 2023-03-27 06:16:08 Assertion in pgstat_assoc_relation() fails intermittently