Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

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.