[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