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

From Nikolay Shaplov
Subject Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind
Date
Msg-id 1756891.5znqRt8KMB@nataraj-amd64
Whole thread Raw
In response to Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
В письме от 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



pgsql-hackers by date:

Previous
From: Nikolay Shaplov
Date:
Subject: Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet
Next
From: Murtuza Zabuawala
Date:
Subject: Login into PostgreSQL without password