Re: Declarative partitioning

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Declarative partitioning
Дата
Msg-id CA+Tgmoamx+gCgUH965_Yrnh9FdYnCJxJdqtNRomaKgbbt6mUXg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Declarative partitioning  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Declarative partitioning
Список pgsql-hackers
On Mon, Nov 23, 2015 at 1:44 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> I support building incrementally, but I don't see why we want to
>> change the catalog structure and then change it again.  That seems
>> like it makes the project more work, not less.
>
> I agree with what you say.  I thought you were saying that the
> implementation had to provide multi-partitioning from the get-go, not
> just the design.

Well, I *hope* that's going to fall out naturally.  If it doesn't, I
can live with that.  But I hope it will.

>> To me, it seems like there is a pretty obvious approach here: each
>> table can be either a plain table, or a partition root (which can look
>> just like an empty inheritance parent).  Then multi-level partitioning
>> falls right out of that design without needing to do anything extra.
>
> Sounds reasonable.

Cool.

>> I think it is also worth getting the syntax right from the beginning.
>
> Yes, that's critical.  We could implement the whole thing in gram.y and
> then have the unsupported cases throw errors; then it's easy to see that
> there are no grammar conflicts to deal with later.

That's worth considering, too.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: parallelism and sorting
Следующее
От: Robert Haas
Дата:
Сообщение: Re: custom function for converting human readable sizes to bytes