Re: [PATCH] get rid of StdRdOptions, use individual binary reloptionsrepresentation for each relation kind instead

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: [PATCH] get rid of StdRdOptions, use individual binary reloptionsrepresentation for each relation kind instead
Дата
Msg-id CA+q6zcUKQKXi_5z50=s01cah5BFQJ+pe_s3iO6oM_jG3RGRHyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead  (Nikolay Shaplov <dhyan@nataraj.su>)
Ответы Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead  (Nikolay Shaplov <dhyan@nataraj.su>)
Список pgsql-hackers
> On Mon, Nov 19, 2018 at 2:30 PM Nikolay Shaplov <dhyan@nataraj.su> wrote:
>
> В письме от 2 октября 2018 13:46:13 пользователь Michael Paquier написал:
> > On Fri, Sep 14, 2018 at 09:30:25PM +0300, Nikolay Shaplov wrote:
> > > BTW this commit shows why do this patch is important: 857f9c36 adds new
> > > option for b-tree indexes. But thanks to the StdRdOptions this option
> > > will exist for no practical use in all heaps that has just any option set
> > > to non-default value, and in indexes that use StdRdOptions (and also has
> > > any option set) And there will be more. StdRdOptions is long outdated
> > > solution and it needs to be replaced.
> >
> > This patch does not apply anymore, so this is moved to next CF, waiting
> > for author.
> Oup...It seems to me that I've fogot to rebase it when it is needed...
> Did it now

Looks like there are some problems with this patch on windows:

src/backend/access/common/reloptions.c(1469): error C2059: syntax error : '}'

https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.22359

> On Fri, Mar 2, 2018 at 8:28 PM Andres Freund <andres@anarazel.de> wrote:
>
> On 2018-03-02 20:22:21 +0300, Nikolay Shaplov wrote:
> > Since I get a really big patch as a result, it was decided to commit it in
> > parts.
>
> I get that, but I strongly suggest not creating 10 loosely related
> threads, but keeping it as a patch series in one thread. It's really
> hard to follow for people not continually paying otherwise.

Totally agree. Probably this also makes it harder to see the big picture behind
this patch - which is in turn probably preventing it from getting some more
review. I hope it doesn't sounds ridiculous, taking into account your efforts
by splitting the patch, but maybe it makes sense to gather these pieces
together (as a separate commits, of course) in one thread?


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dmitry Dolgov
Дата:
Сообщение: Re: NOTIFY and pg_notify performance when deduplicating notifications
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pgsql: Switch pg_verify_checksums back to a blacklist