DBLINK_GET_RESULT(3)

πŸ“¦ version 14.24, in opensuse-leap 16.0

Okay so this is the dblink_get_result(3) page from the PostgreSQL 14.24 Documentation era β€” pull up a chair, we're learning how to collect async query results and it's honestly iconic.


🌸 NAME 🌸

dblink_get_result β€” literally just gets an async query result. That's the whole gig. πŸ’–


πŸ¦‹ SYNOPSIS πŸ¦‹

dblink_get_result(text connname [, bool fail_on_error]) returns setof record

✨ DESCRIPTION ✨

So dblink_get_result collects the results of an asynchronous query that you previously sent with dblink_send_query. No cap. πŸŽ€

And if the query isn't done yet? It just waits. Like, it will sit there and wait until the query completes, patiently, main character energy. ⏳


πŸ’œ ARGUMENTS πŸ’œ

  • connname β€” the name of the connection you're using. The one you already set up. 🫢
  • fail_on_error β€” if it's true (and it's true by default when you omit it), then an error thrown on the remote side of the connection causes an error to also be thrown locally. If it's false, that remote error gets reported locally as a NOTICE instead, and the function returns no rows. Your call, bestie. πŸ™ˆ

🌈 RETURN VALUE 🌈

For an async query β€” that is, an SQL statement returning rows β€” the function returns the row(s) produced by the query. But heads up πŸ‘‘: to use this function you'll need to specify the expected set of columns, exactly like we already talked about for dblink.

For an async command β€” that is, an SQL statement not returning rows β€” the function returns a single row with a single text column containing the command's status string. And yes, it is still necessary to specify that the result will have a single text column in the calling FROM clause. Don't skip that part, fr fr. πŸ’…


πŸ”₯ NOTES πŸ”₯

This function must be called if dblink_send_query returned 1. The way that this works: it must be called once for each query sent, and one additional time to obtain an empty set result, before the connection can be used again. Periodt. πŸ“‹

Okay so this next one is the real talk moment: when using dblink_send_query and dblink_get_result, dblink fetches the entire remote query result before returning any of it to the local query processor. If the query returns a large number of rows, this can result in transient memory bloat in the local session. 😭

So what's better? Open such a query as a cursor with dblink_open and then fetch a manageable number of rows at a time. Alternatively, use plain dblink(), which avoids memory bloat by spooling large result sets to disk. Slay. πŸ“


⭐ EXAMPLES ⭐

contrib_regression=# SELECT dblink_connect('dtest1', 'dbname=contrib_regression');
 dblink_connect
----------------
 OK
(1 row)

contrib_regression=# SELECT * FROM
contrib_regression-# dblink_send_query('dtest1', 'select * from foo where f1 < 3') AS t1;
 t1
----
  1
(1 row)

contrib_regression=# SELECT * FROM dblink_get_result('dtest1') AS t1(f1 int, f2 text, f3 text[]);
 f1 | f2 |     f3
----+----+------------
  0 | a  | {a0,b0,c0}
  1 | b  | {a1,b1,c1}
  2 | c  | {a2,b2,c2}
(3 rows)

contrib_regression=# SELECT * FROM dblink_get_result('dtest1') AS t1(f1 int, f2 text, f3 text[]);
 f1 | f2 | f3
----+----+----
(0 rows)

contrib_regression=# SELECT * FROM
contrib_regression-# dblink_send_query('dtest1', 'select * from foo where f1 < 3; select * from foo where f1 > 6') AS t1;
 t1
----
  1
(1 row)

contrib_regression=# SELECT * FROM dblink_get_result('dtest1') AS t1(f1 int, f2 text, f3 text[]);
 f1 | f2 |     f3
----+----+------------
  0 | a  | {a0,b0,c0}
  1 | b  | {a1,b1,c1}
  2 | c  | {a2,b2,c2}
(3 rows)

contrib_regression=# SELECT * FROM dblink_get_result('dtest1') AS t1(f1 int, f2 text, f3 text[]);
 f1 | f2 |      f3
----+----+---------------
  7 | h  | {a7,b7,c7}
  8 | i  | {a8,b8,c8}
  9 | j  | {a9,b9,c9}
 10 | k  | {a10,b10,c10}
(4 rows)

contrib_regression=# SELECT * FROM dblink_get_result('dtest1') AS t1(f1 int, f2 text, f3 text[]);
 f1 | f2 | f3
----+----+----
(0 rows)

Notice how we keep calling it and keep getting empty sets β€” that's the vibe check. Each call drains a little more, and that last empty one is the ✨ final ✨ one that frees up the connection again. 🧚


That's the whole page, bestie β€” go forth and collect your async results responsibly. πŸ’–

PostgreSQL 14.24 Β· 2026 Β· DBLINK_GET_RESULT(3) β€” mwah, catch you in the next man page πŸ˜˜πŸ¦‹

πŸ“¦ where this page comes from