| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: dubious optimization of the function in SELECT INTO target list |
| Date: | 2015-10-08 17:54:39 |
| Message-ID: | 20151008175439.GJ4405@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Emi | 2015-10-08 19:51:29 | blank in query - cannot return results |
| Previous Message | Ramalingam, Sankarakumar | 2015-10-08 15:27:58 | Re: postgres standby won't start |