В письме от 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
> =odmakk5ti...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to