Search Postgresql Archives

Re: dubious optimization of the function in SELECT INTO target list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 08 Oct 2015, at 19:54, Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> wrote:

Oleksii Kliukin wrote:

Thank you, now it’s clear. I have to say there is no guarantee that
the computation would be useless. Someone might be calling a function
that updates/deletes rows in the SELECT INTO block, being forced to
use SELECT INTO by inability of pl/pgSQL to just discard the result of
a normal SELECT. I know one can use a loop or call PERFORM, but in
some cases (a complex CTE computing the data for the function being
called at the end, which updates the tables with this data) actually
using SELECT INTO looks like the easiest path to achieve the desired
result.

So this whole issue is just because it is not possible to use PERFORM
alongside WITH?

The issue is in the SELECT INTO behaviour, but the root cause is exactly the lack of support for perform in CTEs in pl/pgSQL.

Kind regards,
--
Oleksii


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux