DBLINK_OPEN(3)

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

okay so. you want to open a cursor in a remote database?? iconic. this is the page for you. it's from the PostgreSQL 18.6 Documentation, and yes we're reading a 3 manual page together, it's a whole vibe πŸ¦‹


✨ NAME ✨

dblink_open β€” opens a cursor in a remote database. that's it. that's the whole job. she's a one-trick pony and she slays at it πŸ’…


🌸 SYNOPSIS 🌸

dblink_open(text cursorname, text sql [, bool fail_on_error]) returns text
dblink_open(text connname, text cursorname, text sql [, bool fail_on_error]) returns text

two whole forms, bestie. pick your fighter 🫢


πŸŽ€ DESCRIPTION πŸŽ€

so dblink_open() opens a cursor in a remote database. and then?? the cursor can subsequently be manipulated with dblink_fetch() and dblink_close(). it's giving teamwork. it's giving choreography. the three of them literally cannot function without each other 😭


πŸ¦‹ ARGUMENTS πŸ¦‹

  • connname β€” the name of the connection you wanna use. lowkey optional tho: omit this parameter to use the unnamed connection. no name? no problem ✨
  • cursorname β€” the name you're assigning to this cursor. you get to pick it. main character naming energy, use it wisely πŸ‘‘
  • sql β€” the SELECT statement you wish to execute in the remote database. for example select * from pg_class. fr fr, that's the actual example they gave, we keep it verbatim πŸ’–
  • fail_on_error β€” okay so if this is true (which is 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. equal-opportunity erroring. but if it's false, then the remote error gets reported locally as a NOTICE instead, and the function's return value is set to ERROR. so it's not silent, it's just chill about it πŸ™ˆ

⭐ RETURN VALUE ⭐

returns status. either OK or ERROR. that's the whole menu, bestie πŸ“


πŸ”₯ NOTES πŸ”₯

okay this part actually matters so lock in πŸ”’

a cursor can only persist within a transaction. because of that, dblink_open starts an explicit transaction block (BEGIN) on the remote side β€” if the remote side was not already within a transaction. and then that transaction gets closed again when the matching dblink_close is executed. cute, right?? it cleans up after itself 🧚

⚠️ BUT WAIT. if you use dblink_exec to change data between dblink_open and dblink_close, and then an error occurs, or you use dblink_disconnect before dblink_close, your change will be lost β€” because the transaction will be aborted. not "maybe lost". LOST. gone. poof πŸ’€ so please, for the love of everything, mind your ordering.

🌈 EXAMPLES 🌈

look at her go. actual working code, verbatim, no cap:

SELECT dblink_connect('dbname=postgres options=-csearch_path=');
 dblink_connect
----------------
 OK
(1 row)

SELECT dblink_open('foo', 'select proname, prosrc from pg_proc');
 dblink_open
-------------
 OK
(1 row)

connect, then open, then OK twice. it's giving flawless. it's giving ate and left no crumbs πŸ‘‘


and that's the page!! this whole thing is PostgreSQL 18.6, dated 2026, and it lives in section 3 of the manual as DBLINK_OPEN(3). go open some cursors responsibly bestie, ily, mwah πŸ’–πŸ’…βœ¨

πŸ“¦ where this page comes from