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

Tom Lane wrote: > Alvaro Herrera writes: > > Nikolay Shaplov wrote: > >> Story start from the point that I found out that a.m. can not forbid > >> changing > >> some of it's reloptions with ALTER INDEX command. > > > Hmm, this sounds like a bug to me. In BRIN, if you

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

Alvaro Herrera writes: > Nikolay Shaplov wrote: >> Story start from the point that I found out that a.m. can not forbid >> changing >> some of it's reloptions with ALTER INDEX command. > Hmm, this sounds like a bug to me. In BRIN, if you change the > pages_per_range

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

Nikolay Shaplov wrote: > В письме от 27 мая 2016 15:05:58 Вы написали: > > Nikolay Shaplov wrote: > > > Story start from the point that I found out that a.m. can not forbid > > > changing some of it's reloptions with ALTER INDEX command. That was not > > > necessary before, because all reloptions

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

В письме от 27 мая 2016 15:05:58 Вы написали: > Nikolay Shaplov wrote: > > Story start from the point that I found out that a.m. can not forbid > > changing some of it's reloptions with ALTER INDEX command. That was not > > necessary before, because all reloptions at that existed at that time can

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

Nikolay Shaplov wrote: > Story start from the point that I found out that a.m. can not forbid changing > some of it's reloptions with ALTER INDEX command. That was not necessary > before, because all reloptions at that existed at that time can be changed on > fly. But now for bloom index it

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

В письме от 24 мая 2016 17:12:16 пользователь Nikolay Shaplov написал: While working on this patch I met some difficulties that makes me to completely rewrite a code that is responsible for interacting reloptions.c with access methods. Story start from the point that I found out that a.m. can

Re: [HACKERS] [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 > > >

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

On Wed, May 25, 2016 at 3:03 PM, Alvaro Herrera wrote: > > Nikolay Shaplov wrote: > > В письме от 25 мая 2016 13:25:38 Вы написали: > > > Teodor Sigaev wrote: > > > > >This all should me moved behind "access method" abstraction... > > > > > > > > +1 relopt_kind should be

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

Nikolay Shaplov wrote: > В письме от 25 мая 2016 13:25:38 Вы написали: > > Teodor Sigaev wrote: > > > >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

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

В письме от 25 мая 2016 13:25:38 Вы написали: > Teodor Sigaev wrote: > > >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

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

Teodor Sigaev wrote: > >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. -- Álvaro Herrera

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

This all should me moved behind "access method" abstraction... +1 relopt_kind should be moved in am, at least. Or removed. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via

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

Robert Haas wrote: > On Tue, May 24, 2016 at 10:12 AM, Nikolay Shaplov > wrote: > > While working on patch for attribute options for indexes (see > > http://www.postgresql.org/message-id/5213596.TqFRiqmCTe@nataraj-amd64 ) > > I found out that code for reloptions is not

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

On Tue, May 24, 2016 at 10:12 AM, Nikolay Shaplov wrote: > While working on patch for attribute options for indexes (see > http://www.postgresql.org/message-id/5213596.TqFRiqmCTe@nataraj-amd64 ) > I found out that code for reloptions is not flexible at all. > > All

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

While working on patch for attribute options for indexes (see http://www.postgresql.org/message-id/5213596.TqFRiqmCTe@nataraj-amd64 ) I found out that code for reloptions is not flexible at all. All definitions of attoptons are stored in central catalog in