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

> On 08 Oct 2015, at 19:54, Alvaro Herrera 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 >

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

> On 08 Oct 2015, at 16:00, Adrian Klaver wrote: > > On 10/08/2015 01:57 AM, Oleksii Kliukin wrote: >> >>> On 06 Oct 2015, at 23:31, Tom Lane >> >>> >> wrote: >>> >>> Oleksii Kliukin mailto:al...@hintbits.com> >

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

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

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

On 10/08/2015 01:57 AM, Oleksii Kliukin wrote: On 06 Oct 2015, at 23:31, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: Oleksii Kliukin mailto:al...@hintbits.com>> writes: This should work, but I'm interested in finding out why the original statement behaves the way I’ve described. plpgsql's S

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

> On 06 Oct 2015, at 23:31, Tom Lane wrote: > > Oleksii Kliukin writes: >> This should work, but I'm interested in finding out why the original >> statement behaves the way I’ve described. > > plpgsql's SELECT INTO is only capable of storing a single result row, > so it only executes the sta

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

> On 06 Oct 2015, at 23:11, Adrian Klaver wrote: > > On 10/06/2015 02:00 PM, Oleksii Kliukin wrote: >> >>> On 06 Oct 2015, at 22:50, Adrian Klaver >> > wrote: >>> >>> On 10/06/2015 01:48 PM, Oleksii Kliukin wrote: > On 06 Oct 2015, at 22:40, Adrian K

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

Oleksii Kliukin writes: > This should work, but I'm interested in finding out why the original > statement behaves the way I’ve described. plpgsql's SELECT INTO is only capable of storing a single result row, so it only executes the statement far enough to obtain one row, and then stops (as tho

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

On 10/06/2015 02:00 PM, Oleksii Kliukin wrote: On 06 Oct 2015, at 22:50, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: On 10/06/2015 01:48 PM, Oleksii Kliukin wrote: On 06 Oct 2015, at 22:40, Adrian Klaver mailto:adrian.kla...@aklaver.com> > wrote

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

> On 06 Oct 2015, at 22:50, Adrian Klaver wrote: > > On 10/06/2015 01:48 PM, Oleksii Kliukin wrote: >> >>> On 06 Oct 2015, at 22:40, Adrian Klaver >> >>> >> >>> wrote: >>> >>> On 10/06/2015

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

On 10/06/2015 01:48 PM, Oleksii Kliukin wrote: On 06 Oct 2015, at 22:40, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: On 10/06/2015 01:13 PM, Oleksii Kliukin wrote: Basically, if we invoke the first example, the foo table with have only 1 row and not 10, as supplied by the generat

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

> On 06 Oct 2015, at 22:40, Adrian Klaver wrote: > > On 10/06/2015 01:13 PM, Oleksii Kliukin wrote: >> >> Basically, if we invoke the first example, the foo table with have only >> 1 row and not 10, as supplied by the generate_series. >> However, when ORDER BY is attached to the query, or aggre

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

On 10/06/2015 01:13 PM, Oleksii Kliukin wrote: Hello, I have an issue with a function that is called as a part of the SELECT INTO target list in pl/pgSQL. I'd like to illustrate it with a simple example: DO $$ DECLARE l_id integer; BEGIN SELECT test(id) INTO l_id FROM gene

[GENERAL] dubious optimization of the function in SELECT INTO target list

Hello, I have an issue with a function that is called as a part of the SELECT INTO target list in pl/pgSQL. I'd like to illustrate it with a simple example: DO $$ DECLARE l_id integer; BEGIN SELECT test(id) INTO l_id FROM generate_series(1,10) t(id); END; $$ LANGUAGE plpgs