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.
There may be some other AM properties that would be better to expose
through SQL functions because they could potentially change without
invalidating information stored in the other catalogs. I'm not sure
whether there is any such data that needs to be accessible at SQL
level, though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
