Re: PL/pgSQL PERFORM with CTE

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: PL/pgSQL PERFORM with CTE
Дата
Msg-id CAFj8pRCcpSANqUDfZx3M5xf42N=EVH=Zz4+keoA_wDHPOamARA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PL/pgSQL PERFORM with CTE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PL/pgSQL PERFORM with CTE
Список pgsql-hackers



2013/8/27 Tom Lane <tgl@sss.pgh.pa.us>
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2013/8/27 David E. Wheeler <david@justatheory.com>
>> But whatever the keyword, I think it makes sense to require one to return
>> results to the caller. Any query that does not return, yield, or capture
>> (select into) values should just have its results discarded.

> A usual and first solution and syntax is defined by Sybase - we can define
> own syntax, but I don't think so it is necessary be original everywhere.
> My opinion is surely subjective - this feature is one from few features
> that are nice on T-SQL.

We aren't following T-SQL on any other syntax detail, so why would we
start with this one?  plpgsql is meant to follow Oracle syntax not T-SQL.

I agree with David that we should use some new syntax to specify
return-results-directly-to-client, assuming we ever get any such
functionality.  It seems like a pretty bad choice of default behavior,
which is essentially what you're saying it should be.

this functionality should be disabled in functions. This can be allowed only for procedures started by CALL statements. I don't propose it for functions.

Regards

Pavel
 

                        regards, tom lane

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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: pg_restore multiple --function options
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Behaviour of take over the synchronous replication