Re: [HACKERS] Macros bundling RELKIND_* conditions

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: [HACKERS] Macros bundling RELKIND_* conditions
Дата
Msg-id 20181221.122027.228518886.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Macros bundling RELKIND_* conditions  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список pgsql-hackers
Mmm. My mail on this topic seems to have sent to nowhere..

At Fri, 21 Dec 2018 07:50:04 +0530, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote in
<CAExHW5s+MihMrGmtrUXzR7b6DV2uminqRcgXDw_FVjmHi3VL9Q@mail.gmail.com>
> On Wed, Dec 19, 2018 at 11:37 PM Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
> 
> > On 2017-Aug-02, Tom Lane wrote:
> >
> > > I think Peter's got the error and the detail backwards.  It should be
> > > more like
> > >
> > > ERROR: "someview" cannot have constraints
> > > DETAIL: "someview" is a view.
> > >
> > > If we do it like that, we need one ERROR message per error reason,
> > > and one DETAIL per relkind, which should be manageable.
> >
> > I support this idea.  Here's a proof-of-concept patch that corresponds
> > to one of the cases that Ashutosh was on about (specifically, the one
> > that uses the RELKIND_CAN_HAVE_STORAGE macro I just added).  If there
> > are no objections to this approach, I'm going to complete it along these
> > lines.
> >
> > I put the new function at the bottom of heapam.c but I think it probably
> > needs a better place.
> >
> > BTW are there other opinions on the RELKIND_HAS_STORAGE vs.
> > RELKIND_CAN_HAVE_STORAGE debate?  I'm inclined to change it to the
> > former.
> >
> 
> +1 I liked the idea.

+1. as I posted to another thread [1]. 

[1] https://www.postgresql.org/message-id/20181218.145600.172055615.horiguchi.kyotaro@lab.ntt.co.jp

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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

Предыдущее
От: Edmund Horner
Дата:
Сообщение: Re: Tid scan improvements
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Improve selectivity estimate for range queries