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

Hi,

looks OK to me. I have cherry-picked it from master, because the
attached patch didn't apply.

Pushed. Thanks.

Cheers
Radek

On Thu, 2012-02-09 at 19:27 +0100, Lionel Elie Mamane wrote:
> 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.
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice