From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: No longer possible to query catalogs for index capabilities? |
Date: | 2016-07-25 14:20:05 |
Message-ID: | 20160725142005.GX4028@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Andrew Gierth (andrew(at)tao11(dot)riddles(dot)org(dot)uk) wrote:
> >>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> >> With the gutting of pg_am in 9.6, there seems to be no longer any
> >> way for a query of the system catalogs to discover any of the index
> >> capabilities that were formerly columns in pg_am (notably
> >> amcanorder, amcanorderbyop, amclusterable, amsearcharray,
> >> amsearchnulls).
>
> >> Am I missing something or is this a significant oversight?
>
> Tom> It's absolutely not an oversight. We asked when 65c5fcd35 went in
> Tom> whether there was still any need for that information to be
> Tom> available at the SQL level, and nobody appeared to care.
>
> Perhaps you were asking the wrong people?
The capabilities strike me as useful to expose, they're pretty useful to
know. I believe we were right to hide the APIs/functions and don't see
any need to expose those to the SQL level.
> Tom> We could in theory expose a view to show the data --- but since a
> Tom> large part of the point of that change was to not need initdb for
> Tom> AM API changes, and to not be constrained to exactly
> Tom> SQL-compatible representations within that API, I'm disinclined to
> Tom> do so without a fairly compelling argument why it's needed.
>
> It could easily be exposed as a function interface of the form
> index_has_capability(oid,name) or indexam_has_capability(oid,name)
> without any initdb worries.
Hmm, that seems pretty reasonable.
> That would surely be better than the present condition of being
> completely unable to get this information from SQL.
Agreed.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2016-07-25 14:21:21 | Re: AdvanceXLInsertBuffer vs. WAL segment compressibility |
Previous Message | Andrew Gierth | 2016-07-25 14:13:02 | Re: No longer possible to query catalogs for index capabilities? |