<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - Open Sub-Form causes PostgreSQL error" href="https://bugs.documentfoundation.org/show_bug.cgi?id=119569#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - Open Sub-Form causes PostgreSQL error" href="https://bugs.documentfoundation.org/show_bug.cgi?id=119569">bug 119569</a> from <a class="email" href="mailto:lionel@mamane.lu" title="Lionel Elie Mamane <lionel@mamane.lu>"> Lionel Elie Mamane</a> <pre>(In reply to Albrecht Dreß from <a href="show_bug.cgi?id=119569#c17">comment #17</a>) > (In reply to Lionel Elie Mamane from <a href="show_bug.cgi?id=119569#c16">comment #16</a>) >> 3) If that fails, try to execute the SQL _unchanged_ as a statement (without >> normal LibreOffice processing) > […] >> what you see is the result of step 3, so "it works as designed". > To be honest, I doubt that /any/ halfway SQL-compliant server will ever > accept the broken statement. That algorithm is used on _all_ queries / SQL commands executed by LibreOffice (when column information is needed). So it is "broken" when there are parameters, but it is 100% legit when there are no parameters, and actually corresponds to trying to send the SQL command/query as unchanged as possible to the DB engine. Subforms just happen to use a parametrised query, which is why you see it with subforms. >> Unless, Albrecht, you explain to me why it is a problem? > I fully agree with you that from the users pov Libreoffice behaves as > expected, and that PostgreSQL can deal with broken input properly. > However, from the IT operations pov, it *is* a problem. > In our use case, the database is running on a central server with high > security requirements. We run several monitoring components, inter alia > (using CheckMK) monitoring the PostgreSQL log file for issues. Every > “ERROR” there is of course brought to the admin's attention – remember that > it may be a serious server issue, or an indicator for attack or compromise. I see. Well, let's give it a try. I'll change the algorithm to do only step 4, or maybe turn the algorithm around: first step 4, if that fails step 2 or 3, then step 3 or 2. I'll sleep on it to take a decision on the alternatives. Then in the next months let's see what regressions this brings, or not. Maybe I'll do: step 4 if that fails, step2&3 or 3&2 with, if those succeed, a debug message "if you see this, please file a bug and inform Lionel, should not happen"</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>