В письме от 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: http://www.postgresql.org/mailpref/pgsql-hackers
