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.
