Re: poll: CHECK TRIGGER?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: poll: CHECK TRIGGER?
Дата
Msg-id CA+TgmobVjdzRLNk6Vfngwt=0ud_2sdBAB-102ESwFyURAwJp+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: poll: CHECK TRIGGER?  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: poll: CHECK TRIGGER?
Список pgsql-hackers
On Fri, Mar 9, 2012 at 5:09 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Well, that just means that it'd be a good idea for that function to be
>> supplied by the same shared library that supplies the plpgsql execution
>> functions.  There wouldn't need to be any connection that the core
>> system particularly understands.  So, like Peter, I'm not quite sure
>> what distinction is meant to be drawn by "internal" vs "external".
>
> internal - implement in core, external - implement in extension.
[...]
> I cannot to move plpgsql checker to extension, because there is
> dependency on plpgsql lib, and this is problem. If I can do it, then I
> did it

I don't object to having this feature live in src/pl/plpgsql, and I
don't think Tom's objecting to that either.  I just don't think it
needs any particular support in src/backend.

> I don't see a reason why we need a multiple checkers - checkers are
> parametrised, so there are no real reason, But what statement will be
> maintain this catalog - CREATE CHECK ? You need DROP, ALTER, .. it is
> lot code too.

If the checkers are written by different people and shipped
separately, then a parameter interface does not make anything better.

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


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: poll: CHECK TRIGGER?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: pg_crypto failures with llvm on OSX