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
>
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 |