Sigh ...   Reckon it’s fairly easy to see how to do that, say with the join() function, or maybe with Data::Dumper.   There are lots of ways to implement my suggestion, if one cares to do so, and I don’t think that every single suggestion has to be accompanied by extemporaneously-written Perl source code.   I’m just not as good at that, as other people are!

Often, my own logging-messages are more app-specific anyhow.   I don’t necessarily need to see the actual SQL-string; what I really need to know are the parameters (and these in application terms) that were sent in to it.   I already know, from the validation test-suite, that the query is correctly written and that it produces the intended results.   (Of course, of course ... Mmmmm...??)   So what I really want to know most is what are the values that are being given at that particular point.   A dump – even literally a Data::Dumper dump – of the input parameters to a function might actually be the most useful, because I already know from validation-tests that the function itself works.

One more thought:   be certain that these types of results appear only in log-files, never in anything that might be sent back to a web-browser.   Yes, you can exploit a web-site by causing it to fail and then “stuffing” the debugging-messages that were meant only to be seen by the developer.