On 2015-08-10 18:08, Tom Lane wrote:
> Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
>> On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> There are a couple of other pg_am columns, such as amstorage and
>>> amcanorderbyop, which similarly bear on what's legal to appear in
>>> related catalogs such as pg_opclass. I'd be sort of inclined to
>>> leave those in the catalog as well. I do not see that exposing
>>> a SQL function is better than exposing a catalog column; either
>>> way, that property is SQL-visible.
>
>> That answers my question, thanks!
>
> BTW, just to clarify: we can still have the desirable property that
> CREATE INDEX ACCESS METHOD needs no parameters other than the AM handler
> function name. The AM code would still expose all of its properties
> through the struct returned by the handler. What is at issue here is
> how information in that struct that needs to be available to SQL code
> gets exposed. We can do that either by exposing SQL functions to get
> it, or by having CREATE INDEX ACCESS METHOD call the handler and then
> copy some fields into the new pg_am row. I'm suggesting that we should
> do the latter for any fields that determine validity of pg_opclass,
> pg_amop, etc entries associated with the AM type. The AM could not
> reasonably change its mind about such properties (within a major
> release at least) so there is no harm in making a long-lived copy
> in pg_am. And we might as well not break SQL code unnecessarily
> by removing fields that used to be there.
>
That's definitely the case for built-in AMs but 3rd party ones won't
necessarily follow PG release schedule/versioning and I can imagine
change of for example amcanorderbyop between AM releases as the AM
matures. This could probably be solved by some kind of invalidation
mechanism (even if it's some additional SQL).
However I am not sure if using catalog as some sort of cache for
function output is a good idea in general. IMHO it would be better to
just have those options as part of CREATE and ALTER DDL for INDEX ACCESS
METHODS if we store them in pg_am.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services