Re: Assertions in PL/PgSQL

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Assertions in PL/PgSQL
Дата
Msg-id CAFj8pRDX7btrzO1kU-BziA7kYgxZ4MU3yQRR421GRikX+F-cQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Assertions in PL/PgSQL  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Assertions in PL/PgSQL  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers



2013/11/19 Robert Haas <robertmhaas@gmail.com>
On Sun, Nov 17, 2013 at 5:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> [ rebased patch for RAISE WHEN ]
>
> I have to say I do not see the point of this.  It does nothing you
> can't do already with "IF condition THEN RAISE ...".  And frankly
> the RAISE statement has got too darn many options already.  We don't
> need yet more cruft on it that we'll have to maintain forevermore.
>
> If this were improving standards compliance somehow, I'd be okay
> with it; but what other implementation has got this?

This is a fair point.  I think the goal was to get to RAISE ASSERT
WHEN ...; then, if assertions are off, you do nothing; if they're on,
you error.  IF condition THEN RAISE..." isn't a suitable surrogate in
that case because you incur the overhead of testing the condition
regardless.

Now that having been said, I'm a bit wary of adding every new frammish
someone suggests to PL/pgsql.  Many of the things we've added recently
are things I anticipate that I'll never use.

lot of features are popular with some delay. CTE is very popular now, and two years ago only few developers used it. Lot of applications are developed for 9.1 still.

Regards

Pavel
 

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

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: nested hstore patch
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: nested hstore patch