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

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