Re: Relax requirement for INTO with SELECT in pl/pgsql

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Relax requirement for INTO with SELECT in pl/pgsql
Дата
Msg-id CAFj8pRDFkx1Fq=xmmCwB6Djc=z5tzNdPgur-g1MqEwG7fbtZGw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Relax requirement for INTO with SELECT in pl/pgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Relax requirement for INTO with SELECT in pl/pgsql  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers


2016-03-22 6:06 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I can live with SELECT fx(x). It is little bit dangerous, but this risk can
> be easy detected by plpgsql_check.

Dangerous how?

I afraid of useless and forgotten call of functions. But the risk is same like PERFORM - so this is valid from one half. The PERFORM statement holds special semantic, and it is interesting.

But I don't see any risk if we allow SELECT fx(x) without INTO when fx is void function. It is absolutely correct.

 

>> So, I'm -1 on not having any keyword at all.  I have no objection
>> to Merlin's proposal though.  I agree that PERFORM is starting to
>> look a bit silly, since it doesn't play with WITH for instance.

> Isn't time to fix PERFORM instead?

I do not think it can be fixed without embedding knowledge of PERFORM into
the core parser, which I doubt anybody would consider a good idea.

I don't see, why PERFORM should be in core parser? What use case should be fixed?

Regards

Pavel
 

                        regards, tom lane

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: OOM in libpq and infinite loop with getCopyStart()
Следующее
От: David Rowley
Дата:
Сообщение: Re: parallel aggregation - Numeric is unsupported?