Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

В письме от 25 мая 2016 14:03:17 Вы написали:

> > > > >This all should me moved behind "access method" abstraction...
> > > >
> > > > +1 relopt_kind should be moved in am, at least. Or removed.
> > >
> > > Hm, but we have tablespace options too, so I'm not sure that using AM as
> > > abstraction level is correct.
> >
> > We will use am for all indexes, and keep all the rest in relopotion.c for
> > non-indexes. May be divided options catalog into sections one section for
> > each kind.
> That makes sense.  I can review the patch later.
That would be great! ;-)


>
> > And as I also would like to use this code for dynamic attoptions later, I
> > would like to remove relopt_kind at all. Because it spoils live in that
> > case.
> As I remember, Fabrízio (in CC) had a patch for dynamic reloptions, but
> there was some problem with it and we dumped it; see
> https://www.postgresql.org/message-id/CAFcNs+rqCq1H5eXW-cvdti6T-xo2STEkhjREx
> =OdmAkK5tiOOw@mail.gmail.com for previous discussion.

I've read the start of that thread. In my opinion Fabrízio offering quite
different thing. I am speaking about adding options to a new object (access
method or later operator class). You add these options when you create this
object and you have a monopoly of defining options for it.

Fabrízio offers adding options for relkind that already exists. This seems to
be a complex thing. You should resolve conflicts between two extensions that
want to define same option for example. Somehow deal with the situation when
the extension is dropped. Should we remove reloptions created by that
extension from pg_class then?

And moreover, as far as I understand reloptions is about how does relation
operates. And the external extension would not affect this at all. So we are
speaking not about options of a relation, but about extension that want to
store some info about some relation. I think in general this extension should
store it's info into it's own data structures.

May be there is cases when you will really need such behavior. But it is quite
different task, have almost nothing in common with things I am going to do :-)

--
Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company