DBLINK_B...QL_INSERT(3)

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

okay so welcome to the PostgreSQL 16.15 Documentation page for dblink_build_sql_insert(3) β€” yes, the one filed under DBLINK_B...QL_INSERT(3). grab a strawberry πŸ“ and let's go.


πŸ’– NAME πŸ’–

dblink_build_sql_insert builds an INSERT statement using a local tuple, and it replaces the primary key field values with alternative supplied values. iconic behavior tbh ✨


✨ SYNOPSIS ✨

dblink_build_sql_insert(text relname,
                        int2vector primary_key_attnums,
                        integer num_primary_key_atts,
                        text[] src_pk_att_vals_array,
                        text[] tgt_pk_att_vals_array) returns text

πŸŽ€ DESCRIPTION πŸŽ€

lowkey this is the move for selective replication of a local table to a remote database. dblink_build_sql_insert picks a row from the local table based on primary key, then builds an SQL INSERT command that will duplicate that row β€” but with the primary key values replaced by the values in the last argument. to make an exact copy of the row, just specify the same values for the last two arguments. simple as that πŸ’…


🌸 ARGUMENTS 🌸

  • relname β€” name of a local relation, for example foo or myschema.mytab. include double quotes if the name is mixed-case or contains special characters, for example "FooBar"; without quotes, the string will be folded to lower case.
  • primary_key_attnums β€” attribute numbers (1-based) of the primary key fields, for example 1 2.
  • num_primary_key_atts β€” the number of primary key fields.
  • src_pk_att_vals_array β€” values of the primary key fields to be used to look up the local tuple. each field is represented in text form. an error is thrown if there is no local row with these primary key values. 😭
  • tgt_pk_att_vals_array β€” values of the primary key fields to be placed in the resulting INSERT command. each field is represented in text form.

πŸ‘‘ RETURN VALUE πŸ‘‘

returns the requested SQL statement as text. that's it, that's the tea β˜•


🧚 NOTES 🧚

ngl, this changed in PostgreSQL 9.0: the attribute numbers in primary_key_attnums are interpreted as logical column numbers, corresponding to the column's position in SELECT * FROM relname. previous versions interpreted the numbers as physical column positions. there is a difference if any column(s) to the left of the indicated column have been dropped during the lifetime of the table. so yeah β€” know your column lore, bestie 🫢


πŸ”₯ EXAMPLES πŸ”₯

here's the exact vibe:

           SELECT dblink_build_sql_insert('foo', '1 2', 2, '{"1", "a"}', '{"1", "b''a"}');
                        dblink_build_sql_insert
           --------------------------------------------------
            INSERT INTO foo(f1,f2,f3) VALUES('1','b''a','1')
           (1 row)

πŸ’– that's the whole page, bestie β€” brought to you by PostgreSQL 16.15, dated 2026, and filed under DBLINK_B...QL_INSERT(3). mwah 🫢

πŸ“¦ where this page comes from