Re: PL/pgSQL 1.2

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: PL/pgSQL 1.2
Дата
Msg-id CAFj8pRDizHM1PdbTsOSxm04EzZWOicnES77Txb+_7-1fvGVzWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PL/pgSQL 1.2  (Jan Wieck <jan@wi3ck.info>)
Ответы Re: PL/pgSQL 1.2  (Jan Wieck <jan@wi3ck.info>)
Re: PL/pgSQL 1.2  (Joel Jacobson <joel@trustly.com>)
Re: PL/pgSQL 1.2  (Joel Jacobson <joel@trustly.com>)
Список pgsql-hackers



2014-09-04 15:24 GMT+02:00 Jan Wieck <jan@wi3ck.info>:
On 09/04/2014 01:14 AM, Pavel Stehule wrote:
2014-09-03 23:19 GMT+02:00 Hannu Krosing <hannu@2ndquadrant.com
    A more SQL-ish way of doing the same could probably be called COMMAND
    CONSTRAINTS
    and look something like this

    SELECT
    ...
    CHECK (ROWCOUNT BETWEEN 0 AND 1);


It is very near to my proposed ASSERT

Only if the ASSERT syntax would become part of the original statement, it is supposed to check. In Hannu's command constraint example above, the statement that causes the error, and thus will be logged and become identified by the error message, is the actual SELECT (or other DML statement).

this is valid argument.

On second hand, I proposed a ASSERT that was not based on expressions only. There is not a technical issue to write assert with knowledge of related statement.
 

I think I like the COMMAND CONSTRAINT the best so far.

I not, because when it will not be part of SQL, than parser in plpgsql will be more complex. You have to inject SELECT, UPDATE, INSERT, DELETE

Pavel
 


Regards,
Jan

--
Jan Wieck
Senior Software Engineer
http://slony.info

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: missing tab-completion for relation options
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Escaping from blocked send() reprised.