Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD - Mailing list pgsql-hackers

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?
>
>
> cheers
>
>
> andrew
>
>
> -- 
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>
>

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?


2) I would agree that other PLs should get the same detail.  I don't 
know the other ones as I've been only working in pl/perl.