Re: Regarding inclusion of indexes as tables

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Mark Rotteveel <mark(at)lawinegevaar(dot)nl>, PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Regarding inclusion of indexes as tables
Date: 2015-05-10 00:24:44
Message-ID: CADK3HHK2AGt72ABEvmi9VJT4314XyUisLYCzuQhbCxUrq=S=Lg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Deepak,

You are correct, getTables should not be returning indexes, only tables.

patches are welcome!

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 9 May 2015 at 11:15, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:

> Mark Rotteveel <mark(at)lawinegevaar(dot)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
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Alexis Meneses 2015-05-11 21:05:52 Re: BUG on postgresql-9.4-1201-jdbc41 ...
Previous Message Kevin Grittner 2015-05-09 15:15:01 Re: Regarding inclusion of indexes as tables