[PATCH] [REVIEW:3-5] PostgreSQL getColumns()

Lionel Elie Mamane lionel at mamane.lu
Thu Feb 9 10:27:27 PST 2012


getColumns() is a XDatabaseMetadata interface function to get the list
of columns of a table and info on these columns.

The PostgreSQL-SDBC implementation in 3.5.0 has a couple of bugs fixed
by the attached patch.

 - If the table previously had a column that has since been dropped
   (removed), the numbering of the columns has a hole, and in some
   circumstances the dropped column is still shown by getColumns().

   "Still shown" fixed by

+                   "AND NOT pg_attribute.attisdropped "

   which is the boolean in the PostgreSQL internals that says "this
   column has been dropped, don't show it anymore".

   Numbering had a hole was because it was using "attnum", the
   internal PostgreSQL numbering of columns. But this internal
   numbering is not contiguous, as the number of dropped columns are
   *not* recycled. This is fixed by:

   * Removing attnum from the query we send to PostgreSQL.
   * Adapt column numbers (shifted by one) every time a column (after
     attnum) is read.
   * Generate our own numbering and put that in the result.

   Note that "#invalid#" cannot be a table or schema name: character
   '#' is not allowed.


 - Entries were sorted by the concatenation (?) of schema name, table
   name, column name. In rare cases, this could lead to wrong order,
   and is slower anyway. Example:

   library, book, bookID
   library, bookShelf, bookShelfID
   library, book, XID

   is sorted in this order by "concatenation", but in this (correct) order
   when sorting by column:

   library, book, bookID
   library, book, XID
   library, bookShelf, bookShelfID


   "||" is the SQL string concatenation operator.


I don't have a smoking gun fdo# of a "point and click user"-visible
bug of this, partially because our internal code is suspicious about
some of this data... See lcl_sanitizeColumnDescs in
connectivity/source/commontools/TTableHelper.cxx.

But I consider Base also as a programming platform,
user code (scripts) is allowed to call any function in
XDatabaseMetadata with any arguments, and giving a wrong result (data)
back is a bug in itself.

So I'd like to have this all fixed in libreoffice-3-5, too.

-- 
Lionel


More information about the LibreOffice mailing list