Re: [HACKERS] MERGE SQL Statement for PG11

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] MERGE SQL Statement for PG11
Дата
Msg-id CA+TgmoaKmB8fPmTv3u3UMupdpHQ8kPawi9Otw73Y10_dtACk5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] MERGE SQL Statement for PG11  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Jan 29, 2018 at 12:03 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Partitioning doesn't look too bad, so that looks comfortable for PG11,
> assuming it doesn't hit some unhandled complexity.
>
> Including RLS in the first commit/release turns this into a high risk
> patch. Few people use it, but if they do, they don't want me putting a
> hole in their battleship (literally) should we discover some weird
> unhandled logic in a complex new command.
>
> My recommendation would be to support that later for those that use
> it. For those that don't, it doesn't matter so can also be done later.

-1.  Every other feature we've added recently, including partitioning,
has had to decide what to do about RLS before the initial commit, and
this feature shouldn't be exempt.  In general, newer features need to
work with older features unless there is some extremely good
architectural reason why that is unreasonably difficult.  If that is
the case here, I don't see that you've made an argument for it.  The
proper way to avoid having you put a hole in their battleship is good
code, proper code review, and good testing, not leaving that case off
to one side.

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


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

Предыдущее
От: Oliver Ford
Дата:
Сообщение: Re: Add RANGE with values and exclusions clauses to the Window Functions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] MERGE SQL Statement for PG11