Re: proposal: plpgsql - Assert statement

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: plpgsql - Assert statement
Дата
Msg-id CAFj8pRCTkivYrP8rnnzCUoPn74qTA=gpNQVGugGiGfn073Nifw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql - Assert statement  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: proposal: plpgsql - Assert statement  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Дерево обсуждения
Hi

here is updated patch

2015-01-21 23:28 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/21/15 3:10 PM, Pavel Stehule wrote:

is there some agreement on this behave of ASSERT statement?

I would to assign last patch to next commitfest.

Possible changes:

* I would to simplify a behave of evaluating of message expression - probably I disallow NULL there.

 Well, the only thing I could see you doing there is throwing a different error if the hint is null. I don't see that as an improvement. I'd just leave it as-is.

I enabled a NULL - but enforced a WARNING before.
 

* GUC enable_asserts will be supported

 That would be good. Would that allow for enabling/disabling on a per-function basis too?

sure - there is only question if we develop a #option enable|disable_asserts. I have no string idea.
 

* a assert exception should not be handled by PLpgSQL handler -- like CANCEL exception

 +1
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

Вложения

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BRIN range operator class