Message-ID: <b0c24716-96c9-4898-b32e-930df13f7e64@dunslane.net>
Date: Thu, 29 Aug 2024 16:54:15 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pl/pgperl Patch for adding $_FN detail just like triggers have
 for $_TD
To: Mark Murawski <markm-lists@intellasoft.net>,
 pgsql-hackers@lists.postgresql.org
References: <5d3f6ead-fb58-44bd-9ef4-2283af66a664@intellasoft.net>
 <8527bb5f-7507-4b44-badf-4ba53e63f531@intellasoft.net>
 <1b0bef66-f5ae-434e-a9e1-201c5fbab4ce@dunslane.net>
 <102c0925-7ba5-4aec-9160-945d4b5ee4bf@intellasoft.net>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAmwQTAQgARQIbAwIX
 gAIZAQULCQgHAgMiAgEGFQoJCAsCBBYCAwECHgcWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUC
 ZFlxxwUJGVGAbgAKCRCZ+n/LWfw7gXikB/9ZdcUy6CTBFIIuL/bVsc1eLEW/gJBjJBF6HxNY
 xgEkAgXAp4Lg4A5U+QB9GouFr7+GYxF0BU4hzoGhNPUWltxnHdMWP8nC/38LAqgMi8L/bbsm
 HW5YPBdWYaAZAPJQVfOAgjTbRUb26KSprpyrrJKW0ZmrZfjhNPcQ72jpWzoPLQqx2X6B0fru
 1jq+cBh8lb6r1mJTim1T3JIn+F/v5VpdQS+EL8xqsHkfzKjIPsW3CIXpkypSk6saA55Rkkbl
 26AW8ftPVB0Q6Lnn6FLt9CP0MGNixBQ55yq8r1K+nCBvCCjvQjM8RDm0UUum0WNl+ifQgTLO
 E8TWEnwVtkBf+3QWzsBNBE7KWFkBCADRnOM0FCzsYW6jtncg+dWIagjUZpvaClmqn/sJluLa
 Q3v1VXMQJzYs3eC1gh386W+XBwLRpDj3jzH81lX+p73Re3d3oJW7X+ffsxuzu5ZVdMUkqBYo
 nkAbKxr6gyJ12F/+JkUVzLcoTN+d/7YsQvUVi7NaKH8mJgjz112O4fUe3p9wfAaFa0RXHc5S
 GPzRTYRRlv/XZBIho4J2tkZOnteZJZ+GbxQVlINt6fd8P6al3MWOvpP/ExJPguEfjOsO6Njy
 xjo3WfpD4lHMOR/Oc3/8mScEF84rF2jXbsFgelWnbPWAvXY+pD0dXOFRkagGmC/viwBDqq5b
 5tk76kKmUbZxABEBAAHCwHwEGAEIACYCGwwWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUCZFlx
 5wUJGVGAjgAKCRCZ+n/LWfw7gf+iB/4g8CPY5jihf5r/8EsoIGe2H+dpVmpPF8YGBzTIvCz/
 fQoOq8AX/pE76QEuFnFZWfjw+wgBXgCVmkox2Eflkk6z4ND3pcwGZ6CfCxTQCDk/dij+2DQ4
 6bmDCy/sBgcbz9mTpoLC11HLoPae6YN9nBNQRZDcEFEu54OaVOqlIdbA6m+POIBCXZdHOFc0
 WoDTgxHRzC1jgQNidyd6tKqcsVJs0dzF0oKTmFFmUAqTdJO12LBuNA1rlqrR3EtpYk8B/wtS
 5dIMD7Q8hwQpL+4C6GNpb6ZKnPkLi47pDOLhz2qBrqN+rqUEsT3YnExYpzj5yOBi+FlmV1Hw
 49QYe1sn2ZPs
In-Reply-To: <102c0925-7ba5-4aec-9160-945d4b5ee4bf@intellasoft.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/b0c24716-96c9-4898-b32e-930df13f7e64%40dunslane.net>
Precedence: bulk


On 2024-08-29 Th 1:01 PM, Mark Murawski wrote:
>
>
> On 8/29/24 11:56, Andrew Dunstan wrote:
>>
>> On 2024-08-28 We 5:53 PM, Mark Murawski wrote:
>>> Hi Hackers!
>>>
>>> This would be version v1 of this feature
>>>
>>> Basically, the subject says it all: pl/pgperl Patch for being able 
>>> to tell which function you're in.
>>> This is a hashref so it will be possible to populate new and 
>>> exciting other details in the future as the need arises
>>>
>>> This also greatly improves logging capabilities for things like 
>>> catching warnings,  Because as it stands right now, there's no 
>>> information that can assist with locating the source of a warning 
>>> like this:
>>>
>>> # tail -f /var/log/postgresql.log
>>> ******* GOT A WARNING - Use of uninitialized value $prefix in 
>>> concatenation (.) or string at (eval 531) line 48.
>>>
>>> Now, with $_FN you can do this:
>>>
>>>
>>> CREATE OR REPLACE FUNCTION throw_warning() RETURNS text LANGUAGE 
>>> plperlu AS $function$
>>>
>>> use warnings;
>>> use strict;
>>> use Data::Dumper;
>>>
>>> $SIG{__WARN__} = sub {
>>>   elog(NOTICE, Dumper($_FN));
>>>
>>>   print STDERR "In Function: $_FN->{name}: $_[0]\n";
>>> };
>>>
>>> my $a;
>>> print "$a"; # uninit!
>>>
>>> return undef;
>>>
>>> $function$
>>> ;
>>>
>>> This patch is against 12 which is still our production branch. This 
>>> could easily be also patched against newer releases as well.
>>>
>>> I've been using this code in production now for about 3 years, it's 
>>> greatly helped track down issues.  And there shouldn't be anything 
>>> platform-specific here, it's all regular perl API
>>>
>>> I'm not sure about adding testing.  This is my first postgres patch, 
>>> so any guidance on adding regression testing would be appreciated.
>>>
>>> The rationale for this has come from the need to know the source 
>>> function name, and we've typically resorted to things like this in 
>>> the past:
>>>
>>> CREATE OR REPLACE FUNCTION throw_warning() RETURNS text LANGUAGE 
>>> plperlu AS $function$
>>> my $function_name = 'throw_warning';
>>> $SIG{__WARN__} = sub { print STDERR "In Function: $function_name: 
>>> $_[0]\n"; }
>>> $function$
>>> ;
>>>
>>> We've literally had to copy/paste this all over and it's something 
>>> that postgres should just 'give you' since it knows the name 
>>> already, just like when triggers pass you $_TD with all the 
>>> pertinent information
>>>
>>> A wishlist item would be for postgres plperl to automatically 
>>> prepend the function name and schema when throwing perl warnings so 
>>> you don't have to do your own __WARN__ handler, but this is the next 
>>> best thing.
>>
>>
>>
>> I'm not necessarily opposed to this, but the analogy to $_TD isn't 
>> really apt.  You can't know the trigger data at compile time, whereas 
>> you can know the function's name at compile time, using just the 
>> mechanism you find irksome.
>>
>> And if we're going to do it for plperl, shouldn't we do it for other 
>> PLs?
>>
>>
>>
>
> Hi Andrew,
>
>
> Thanks for the feedback.
>
>
> 1) Why is this not similar to _TD?  It literally operates identically. 
> At run-time it passes you $_TD  for triggers.    Same her for 
> functions.  This is all run-time.   What exactly is the issue you're 
> trying to point out?


It's not the same as the trigger data case because the function name is 
knowable at compile time, as in fact you have demonstrated. You just 
find it a bit inconvenient to have to code for that knowledge. By 
contrast, trigger data is ONLY knowable at run time.

But I don't see that it is such a heavy burden to have to write

   my $funcname = "foo";

or similar in your function.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com