On 2015-08-10 18:08, Tom Lane wrote:
Alexander Korotkov <a.korot...@postgrespro.ru> writes:
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
