PegoraroF10 wrote:
> Another approach to solve my problem would be a function that receives a
> dynamic SQL, runs it and returns a XML or JSON and on client side I convert
> that XML back to a recordset. Is that possible ?
Yet another tool that can be handy to transfer polymorphic
results is a cursor through the plpgsql REFCURSORs:
https://www.postgresql.org/docs/10/static/plpgsql-cursors.html
Here's an actual example with a DO block :
BEGIN;
DO $$
DECLARE
c1 refcursor := 'cursor1';
c2 refcursor := 'cursor2';
BEGIN
OPEN c1 FOR select 'result #1 column 1', 'result #1 column 2';
OPEN c2 FOR select 'result #2 column 1', 'result #2 column 2';
END;
$$ LANGUAGE plpgsql;
FETCH cursor1;
FETCH cursor2;
COMMIT;
The interface is a bit weird because the value of the refcursor variable
is the name of the underlying SQL cursor object. The name can
also be auto-generated by postgres; the above code uses fixed
names instead. Anyway that cursor, once instanciated in the
DO block, can be fetched from with FETCH statements initiated
client-side or by other server-side code.
The above code will retrieve two independant resultsets:
postgres=# FETCH cursor1;
?column? | ?column?
--------------------+--------------------
result #1 column 1 | result #1 column 2
(1 row)
postgres=# FETCH cursor2;
?column? | ?column?
--------------------+--------------------
result #2 column 1 | result #2 column 2
(1 row)
These cursors disappear at transaction end, or they can be explicitly
closed with CLOSE statements.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
