operator delete mismatch in ODatabaseMetaDataResultSet

Greetings,

I think I have my very first patch to submit.  "Contributing Patches"
<http://wiki.services.openoffice.org/wiki/Contributing_Patches>
suggests that I take it to [email protected] first, but I am bringing
it here instead.  Here, with some rationales and questions, is what I
contemplate ...

    component       : Database access
    subcomponent    : none
      ( because ODBC is not offered )
    found in version: DEV300_m75
    platform        : other 
    os              : Linux
    priority        : P5
      ( unless some platform is less forgiving than mine, perhaps? )
    issue type      : patch
    initial state   : new
    assigned to     : oj
      ( because that is what
      <http://qa.openoffice.org/issue_handling/submission_gateway.html>
      does when you click "connectivity" )
    summary         : operator delete mismatch in ODatabaseMetaDataResultSet
    description ...
        In file
        connectivity/source/drivers/odbcbase/ODatabaseMetaDataResultSet.cxx,
        line 86 assigns m_pRowStatusArray from array new but line 100
        does a scalar delete.  In a non-production build, this causes
        numerous assertion failures at
        sal/cpprt/operators_new_delete.cxx line 95 when, for example,
        you open a query to an ODBC database.

And then the patch ...

    --- ODatabaseMetaDataResultSet.cxx_m75	2010-03-21 23:37:01.000000000 -0400
    +++ ODatabaseMetaDataResultSet.cxx_tje	2010-03-21 23:38:03.000000000 -0400
    @@ -97,7 +97,7 @@
     		osl_incrementInterlockedCount( &m_refCount );
     		dispose();
     	}
    -	delete m_pRowStatusArray;
    +	delete [] m_pRowStatusArray;
     }
     // -------------------------------------------------------------------------
     void ODatabaseMetaDataResultSet::disposing(void)

I have tested this only to the extent of observing fewer assertions
raised as I open my favourite query against an ODBC database.

Should I say more?  Less?  Something else?  I welcome your comments.

Cheers,
Terry.