Mark Rotteveel <mark@lawinegevaar.nl> wrote:
> [...] having getTables and getColumns return index information
> sounds a bit curious: that is what getIndexInfo is for.
> Is an index in PostgreSQL selectable (as if it is a table) or can
> the index itself be referenced as a column (eg select index from
> table)? If not, I'd suggest that the information should not be
> part of getTables nor of getColumns.
It's somewhat understandable how the driver developers got to this
point, since in the server indexes are considered *relations*, as
are tables, views, materialized views, system catalogs, foreign
tables, etc. On the other hand, unlike other relations they cannot
generally be referenced in SELECT queries or DML statements. A
query can sometimes return data directly from the columns in an
index, but it is the job of the optimizer to recognize when a query
referencing a table can be optimized in this way.
If I were designing this in a green field, I would probably limit
return of indexes to the getIndexInfo() method and filter them out
of scans of relations returned by the getTables() method. That
said, doing so now could break working code for existing users, and
the getTables() method does allow you to specify which table types
you want returned; so I (and probably most of the pg community)
would be reluctant to support filtering them out by default at this
point. We tend to be reluctant to make changes that break working
code for existing users, and want to make a lot of noise about any
such change so that people have a chance to fix it before putting
it into production.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
