Re: cursor empty

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Philipp Kraus <philipp(dot)kraus(at)tu-clausthal(dot)de>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: cursor empty
Date: 2018-05-08 14:18:08
Message-ID: CAKFQuwZxVACPZAaKqzKy9AFDn-vH64Tq6DwRTUExXLa0HfiA4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, May 8, 2018 at 6:36 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

>
>> select * from vectorize('myvec');
>> fetch all from myvec;
>>
>> Can you explain me, which part is wrong?
>>
>
> I am going to say:
>
> perform pivottable( ...
>
> https://www.postgresql.org/docs/10/static/plpgsql-statements
> .html#PLPGSQL-STATEMENTS-SQL-NORESULT
>
> "Sometimes it is useful to evaluate an expression or SELECT query but
> discard the result, for example when calling a function that has
> side-effects but no useful result value. To do this in PL/pgSQL, use the
> PERFORM statement:
>
> PERFORM query;
>
> This executes query and discards the result. ..."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>

​It discards the results but not the side-effect, which in this case is
creating a named portal in the session. While the name of the portal, as
returned by the function, is indeed lost the portal still exists, with the
same name, and since the name is known by the caller anyway the attempt to
make use of the portal succeeds (no failure and the column structure is
known). Maybe you are right about the contents of the portal being lost
due to the perform but that behavior isn't evident from the the section you
quote.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Philipp Kraus 2018-05-08 14:32:25 Re: cursor empty
Previous Message Kumar, Virendra 2018-05-08 13:38:19 Autovacuum holding exclusive lock on table