public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 1/4] demote: setter functions for LocalXLogInsert local variable
6+ messages / 3 participants
[nested] [flat]
* [PATCH 1/4] demote: setter functions for LocalXLogInsert local variable
@ 2020-07-31 08:58 Jehan-Guillaume de Rorthais <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Jehan-Guillaume de Rorthais @ 2020-07-31 08:58 UTC (permalink / raw)
Adds functions extern LocalSetXLogInsertNotAllowed() and
LocalSetXLogInsertCheckRecovery() to set the local variable
LocalXLogInsert respectively to 0 and -1.
These functions are declared as extern for future need in
the demote patch.
Function LocalSetXLogInsertAllowed() already exists and
declared as static as it is not needed outside of xlog.h.
---
src/backend/access/transam/xlog.c | 27 +++++++++++++++++++++++----
src/include/access/xlog.h | 2 ++
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 756b838e6a..25a9f78690 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7711,7 +7711,7 @@ StartupXLOG(void)
Insert->fullPageWrites = lastFullPageWrites;
LocalSetXLogInsertAllowed();
UpdateFullPageWrites();
- LocalXLogInsertAllowed = -1;
+ LocalSetXLogInsertCheckRecovery();
if (InRecovery)
{
@@ -8219,6 +8219,25 @@ LocalSetXLogInsertAllowed(void)
InitXLOGAccess();
}
+/*
+ * Make XLogInsertAllowed() return false in the current process only.
+ */
+void
+LocalSetXLogInsertNotAllowed(void)
+{
+ LocalXLogInsertAllowed = 0;
+}
+
+/*
+ * Make XLogInsertCheckRecovery() return false in the current process only.
+ */
+void
+LocalSetXLogInsertCheckRecovery(void)
+{
+ LocalXLogInsertAllowed = -1;
+}
+
+
/*
* Subroutine to try to fetch and validate a prior checkpoint record.
*
@@ -9004,9 +9023,9 @@ CreateCheckPoint(int flags)
if (shutdown)
{
if (flags & CHECKPOINT_END_OF_RECOVERY)
- LocalXLogInsertAllowed = -1; /* return to "check" state */
+ LocalSetXLogInsertCheckRecovery(); /* return to "check" state */
else
- LocalXLogInsertAllowed = 0; /* never again write WAL */
+ LocalSetXLogInsertNotAllowed(); /* never again write WAL */
}
/*
@@ -9159,7 +9178,7 @@ CreateEndOfRecoveryRecord(void)
END_CRIT_SECTION();
- LocalXLogInsertAllowed = -1; /* return to "check" state */
+ LocalSetXLogInsertCheckRecovery(); /* return to "check" state */
}
/*
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index 221af87e71..8c9cadc6da 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -306,6 +306,8 @@ extern RecoveryState GetRecoveryState(void);
extern bool HotStandbyActive(void);
extern bool HotStandbyActiveInReplay(void);
extern bool XLogInsertAllowed(void);
+extern void LocalSetXLogInsertNotAllowed(void);
+extern void LocalSetXLogInsertCheckRecovery(void);
extern void GetXLogReceiptTime(TimestampTz *rtime, bool *fromStream);
extern XLogRecPtr GetXLogReplayRecPtr(TimeLineID *replayTLI);
extern XLogRecPtr GetXLogInsertRecPtr(void);
--
2.20.1
--MP_/Mp45B_GpB5m14pibp/TRwlo
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=v4-0002-demote-support-demoting-instance-from-production-to-.patch
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD
@ 2024-08-29 15:56 Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Dunstan @ 2024-08-29 15:56 UTC (permalink / raw)
To: Mark Murawski <[email protected]>; [email protected]
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD
@ 2024-08-29 17:01 Mark Murawski <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Mark Murawski @ 2024-08-29 17:01 UTC (permalink / raw)
To: [email protected]
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.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD
@ 2024-08-29 20:54 Andrew Dunstan <[email protected]>
parent: Mark Murawski <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Dunstan @ 2024-08-29 20:54 UTC (permalink / raw)
To: Mark Murawski <[email protected]>; [email protected]
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD
@ 2024-08-29 21:50 Mark Murawski <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Mark Murawski @ 2024-08-29 21:50 UTC (permalink / raw)
To: [email protected]
On 8/29/24 16:54, Andrew Dunstan wrote:
>
> 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
>
>
>
Understood, regarding knowability. Trigger data is definitely going to
be very dynamic in that regard.
No, It's not a heavy burden to hard code the function name. But what my
ideal goal would be is this:
CREATE OR REPLACE FUNCTION throw_warning() RETURNS text LANGUAGE plperlu
AS $function$
use 'PostgresWarnHandler'; # <--- imagine this registers a WARN handler
and outputs $_FN->{name} for you as part of the final warning
my $a;
print $a;
.... etc
and then there's nothing 'hard coded' regarding the name of the
function, anywhere. It just seems nonsensical that postgres plperl
can't send you the name of your registered function and there's
absolutely no way to get it other than hard coding the name
(redundantly, considering you're already know the name when you're
defining the function in the first place)
But even better would be catching the warn at the plperl level,
prepending the function name to the warn message, and then you only need:
CREATE OR REPLACE FUNCTION throw_warning() RETURNS text LANGUAGE plperlu
AS $function$
my $a;
print $a;
.... etc
And then in this hypothetical situation -- magic ensues, and you're left
with this:
# tail -f /var/log/postgresql.log
******* GOT A WARNING - Use of uninitialized value $a in concatenation
(.) or string in function public.throw_warning() line 1
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD
@ 2024-08-30 19:49 Andrew Dunstan <[email protected]>
parent: Mark Murawski <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Dunstan @ 2024-08-30 19:49 UTC (permalink / raw)
To: Mark Murawski <[email protected]>; [email protected]
On 2024-08-29 Th 5:50 PM, Mark Murawski wrote:
>
>
> On 8/29/24 16:54, Andrew Dunstan wrote:
>>
>> 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
>>
>>
>>
>
> Understood, regarding knowability. Trigger data is definitely going
> to be very dynamic in that regard.
>
> No, It's not a heavy burden to hard code the function name. But what
> my ideal goal would be is this:
>
> CREATE OR REPLACE FUNCTION throw_warning() RETURNS text LANGUAGE
> plperlu AS $function$
> use 'PostgresWarnHandler'; # <--- imagine this registers a WARN
> handler and outputs $_FN->{name} for you as part of the final warning
>
> my $a;
> print $a;
>
> .... etc
>
>
> and then there's nothing 'hard coded' regarding the name of the
> function, anywhere. It just seems nonsensical that postgres plperl
> can't send you the name of your registered function and there's
> absolutely no way to get it other than hard coding the name
> (redundantly, considering you're already know the name when you're
> defining the function in the first place)
>
> But even better would be catching the warn at the plperl level,
> prepending the function name to the warn message, and then you only need:
>
> CREATE OR REPLACE FUNCTION throw_warning() RETURNS text LANGUAGE
> plperlu AS $function$
>
> my $a;
> print $a;
>
> .... etc
>
> And then in this hypothetical situation -- magic ensues, and you're
> left with this:
> # tail -f /var/log/postgresql.log
> ******* GOT A WARNING - Use of uninitialized value $a in concatenation
> (.) or string in function public.throw_warning() line 1
>
>
>
>
>
>
>
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-08-30 19:49 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-07-31 08:58 [PATCH 1/4] demote: setter functions for LocalXLogInsert local variable Jehan-Guillaume de Rorthais <[email protected]>
2024-08-29 15:56 Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD Andrew Dunstan <[email protected]>
2024-08-29 17:01 ` Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD Mark Murawski <[email protected]>
2024-08-29 20:54 ` Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD Andrew Dunstan <[email protected]>
2024-08-29 21:50 ` Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD Mark Murawski <[email protected]>
2024-08-30 19:49 ` Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD Andrew Dunstan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox