pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50193psql -h localhost -U postgresBuilt from patchset v3 (message #3), August 17, 2026 at 09:46 AM.
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.
Attachments:
plperl-add-FN-v1.patchtext/x-patch; charset=UTF-8; name=plperl-add-FN-v1.patchDownload+24-0
Import Notes
Reply to msg id not found: ee59ec8a-e257-4af8-a09e-e800a847a6ef@intellasoft.netReference msg id not found: ee59ec8a-e257-4af8-a09e-e800a847a6ef@intellasoft.net
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.
Attachments:
plperl-add-FN-v1.patchtext/x-patch; charset=UTF-8; name=plperl-add-FN-v1.patchDownload+24-0
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.
Attachments:
plperl-add-FN-v1.patchtext/x-patch; charset=UTF-8; name=plperl-add-FN-v1.patchDownload+24-0
We don't really need four copies of this patch.
regards, tom lane
Sorry! I'm having email delivery issues. I thought the first few
didn't go through. I'm working through email DKMS problems where we
were incompatible with the mailing list.
It sounds like it's fixed now! Sorry for the spam!
Show quoted text
On 8/28/24 18:38, Tom Lane wrote:
We don't really need four copies of this patch.
regards, tom lane