DBLINK_GET_RESULT(3)

💅 DBLINK_GET_RESULT(3) 💅

okay bestie, buckle up — this one's from the dblink squad, and it's the function you call to actually go pick up the results of a query you fired off earlier. no cap, it's the "so… did my async query finish or what" function. 🎀

---

✨ NAME ✨

dblink_get_result — gets an async query result. that's it, that's the whole vibe. it fetches. it returns. it slays. 🦋

---

✨ 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. think of it as going back to the drive-thru window to grab the order you placed. 🍓

and if the query isn't already completed? it will wait until it is. literally just standing there. patiently. no thoughts, head empty, just vibing until the remote side is done. 😭

---

✨ ARGUMENTS ✨

• connname — name of the connection to use. which bestie are we talking to rn 💅
• fail_on_error — if true (and heads up, that's the 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 false, the remote error is locally reported as a NOTICE, and the function returns no rows. so like, false = "tell me about it but don't ruin my whole day", true = "if they're dramatic, I'm dramatic too" 💀

---

✨ RETURN VALUE ✨

okay so it depends on what kind of thing you sent:

• for an async query (that is, an SQL statement returning rows) — the function returns the row(s) produced by the query. but to use this function you will need to specify the expected set of columns, as previously discussed for dblink. the function cannot read your mind, bestie, you gotta tell it the shape.
• 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. no skipping that part. 🙈

---

✨ NOTES ✨

• 🚨 this function must be called if dblink_send_query returned 1. 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. yes, one extra. that last empty one is the "we're so done here" signal. don't skip it or the connection is stuck in its feelings.
• 🧠 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. so if the query returns a large number of rows, this can result in transient memory bloat in the local session. it's giving "I asked for a snack and got the whole grocery store."
• 💡 it may be better to 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. both of those are the lowkey responsible choices, iykyk.

---

✨ EXAMPLES ✨

first, connect — icon behaviour only:

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

send the async query:

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

grab the results — note the column list, that's the whole "specify the expected set of columns" thing in action:

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)

and the extra call for the empty set — that's the one we talked about in NOTES:

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

now with two statements in one send. multi-tasking queen:

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)

result from the first statement:

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)

result from the second one — see how it's a whole different batch? one call per result set, bestie:

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)

and the final empty-set call to close it out. periodt. 💅

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

---

okay that's the whole page, you ate that 🫶 this gorgeous little doc came from the PostgreSQL 17.11 documentation, dated 2026, and it's filed under DBLINK_GET_RESULT(3) — go forth and fetch your results responsibly, mwah 💖✨