<html>
    <head>
      <base href="https://bugs.documentfoundation.org/">
    </head>
    <body>
      <p>
        <div>
            <b><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#c17">Comment # 17</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 <span class="vcard"><a class="email" href="mailto:albrecht.dress@arcor.de" title="Albrecht Dreß <albrecht.dress@arcor.de>"> <span class="fn">Albrecht Dreß</span></a>
</span></b>
        <pre>(In reply to Lionel Elie Mamane from <a href="show_bug.cgi?id=119569#c16">comment #16</a>)
Thanks a lot for the detailed description of the bug!

<span class="quote">> 3) If that fails, try to execute the SQL _unchanged_ as a statement (without
> normal LibreOffice processing)</span >
[…]
<span class="quote">> what you see is the result of step 3, so "it works as designed".</span >

To be honest, I doubt that /any/ halfway SQL-compliant server will ever accept
the broken statement.  Would be interesting what Oracle/Mysql/… report in this
case.

<span class="quote">> Unless, Albrecht, you explain to me why it is a problem?</span >

I fully agree with you that from the users pov Libreoffice behaves as expected,
and that PostgreSQL can deal with broken input properly.  In a single-user
environment, I guess ≥99% of the users will even never notice the PostgreSQL
error messages.

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.

With several users using the Libreoffice frontend, the admin gets bombarded
with issues, of which /almost/ all are caused by the Libreoffice bug.  Needles
to say that there is a considerable risk that real issues just slip through.

So, apart from a fixed Libreoffice version, my options are:
(1) Disable monitoring for PostgreSQL (I actually did this temporarily) or
error reporting from PostgreSQL.  No long-term solution as security auditing is
mandatory in our use case, and a /very/ bad idea anyway.
(2) Replace Libreoffice by an other solution.  Drawback: loose all amenities of
Libreoffice, time/money for implementation.
(3) Create a new monitoring component which ignores *only* the broken queries,
iff coming from Libreoffice (but not from other sources).  Probably less effort
than (2), but adds complexity to the setup (maintenance, security auditing of
the new component, etc.)

In short, it's neither “RESOLVED” nor “NOTABUG” for me…

Apart from that, IMHO it's not good engineering practice to issue “something”
which is broken by design and hope that the recipient will deal with it
properly, but this may be philosophical question.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>