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

On 8/30/24 16:12, Andrew Dunstan wrote:
>
> Sorry for empty reply. Errant finger hit send.
>

No problem.

So anyway... my main point is to highlight this:

>
> On 2024-08-29 Th 5:50 PM, Mark Murawski wrote:
>>
>>
>> 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
>>
>>

The essential element here is:  Why does every single developer who ever
wants to develop in plperl be forced to figure out (typically at the
worst possible time) that Postgres doesn't log the source function of
warning.  And then be forced to hard code their own function name as a
variable inside their function.  The typical situation is you test your
code, you push it to production, and then observe.  And then production
does something you didn't expect and throws a warning.  With the current
design, you have no idea what code threw the warning and you have to go
into every single possible plperl function and throw in hard coded
function names for logging. To me this is highly nonsensical to force
this on developers.

Pretty much every modern scripting language I've come across, has a way
to access dynamically: the name of the currently executing function. 
Either by way of a special variable, or a stack trace introspection. 
Being that this is Perl, sure... we can get caller() or a stack trace. 
But the design of plperl Postgres functions uses an anonymous coderef to
define the function, so there is no function name defined. I don't see
the harm in adding more information so that the running function can
know its own name.

Maybe another approach to the fix here is to give the function an actual
name, and when calling it, now you know where you are executing from. 
But in perl you cannot define a sub called schema.function, it
definitely does not compile.  So you would need some sort of name
mangling like postgres_plperl_schema_function so it's painfully obvious
where it came from.  So... this is why it's handy to just have a
variable, since you can format the called schema.function properly.

But, Ideally the even better solution or just catching and re-throwing
the warn handler sounds like it would be the best option.  I'll need to
look into this more since this is really my first jump into the perl-c
api and I've never worked with warn handlers at this level.