Re: PL/pgSQL PERFORM with CTE

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: PL/pgSQL PERFORM with CTE
Дата
Msg-id CAFj8pRBoUeOJfgrWj5oBugvRcVK-85tas+2DjEyKnkoUoNYqdg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PL/pgSQL PERFORM with CTE  ("David E. Wheeler" <david@justatheory.com>)
Ответы Re: PL/pgSQL PERFORM with CTE
Список pgsql-hackers



2013/8/29 David E. Wheeler <david@justatheory.com>
On Aug 29, 2013, at 2:48 PM, Andres Freund <andres@2ndquadrant.com> wrote:

>> You have yet to supply any arguments which support this position.
>
> I am not convinced that's enough of a reason, but the requirement to use
> PERFORM for SELECTs that aren't stored anywhere actually has prevented
> bugs for me. I am not convinced that's worth the cost since I also have
> been annoyed by it several times, but it's not as crystal clear as you
> paint it.

So now we can revise Josh’s assertion to: “I have seen only tepid, unconvincing arguments which support this position.”

I have thought that PERFORM was useful to mark queries that discard results in the past, but I think now that the mental load is higher, even if it can be fixed with CTEs, it’s more trouble than it’s worth.

when we fix a correct call of VOID function, then half of problem goes out. Second half is subjective.

I remember, some years ago there was a proposal to change syntax and remove all verbosity features from PL/pgSQL - for example - using only END instead END IF, END LOOP, ...

For me, this talk is similar - we have a language, that was designed be secure and verbose, what means, so developer must to write some chars more. You cannot to have both - short language and secure.

Regards

Pavel
 

Best,

David


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Variadic aggregates vs. project policy
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: PL/pgSQL PERFORM with CTE