> [...] 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.