--- /srv/reproducible-results/rbuild-debian/r-b-build.Z2NSHEiL/b1/libpqxx_7.9.1-2_armhf.changes +++ /srv/reproducible-results/rbuild-debian/r-b-build.Z2NSHEiL/b2/libpqxx_7.9.1-2_armhf.changes ├── Files │ @@ -1,5 +1,5 @@ │ │ 63dcf0ab3bc80b23f7079d36195dce55 2407832 debug optional libpqxx-7.9-dbgsym_7.9.1-2_armhf.deb │ e097a23cb2dda0a5f133da33e20cf563 176592 libs optional libpqxx-7.9_7.9.1-2_armhf.deb │ 13edd2fbed23ffedf95ad54024c11d5f 362284 libdevel optional libpqxx-dev_7.9.1-2_armhf.deb │ - 85f58562390a7a084d5c4c63a87ed868 2602688 doc optional libpqxx-doc_7.9.1-2_all.deb │ + e0c4528f2e21bc5ab9f60900195b02bb 2602876 doc optional libpqxx-doc_7.9.1-2_all.deb ├── libpqxx-doc_7.9.1-2_all.deb │ ├── file list │ │ @@ -1,3 +1,3 @@ │ │ -rw-r--r-- 0 0 0 4 2024-07-10 18:27:49.000000 debian-binary │ │ --rw-r--r-- 0 0 0 32020 2024-07-10 18:27:49.000000 control.tar.xz │ │ --rw-r--r-- 0 0 0 2570476 2024-07-10 18:27:49.000000 data.tar.xz │ │ +-rw-r--r-- 0 0 0 32000 2024-07-10 18:27:49.000000 control.tar.xz │ │ +-rw-r--r-- 0 0 0 2570684 2024-07-10 18:27:49.000000 data.tar.xz │ ├── control.tar.xz │ │ ├── control.tar │ │ │ ├── ./md5sums │ │ │ │ ├── ./md5sums │ │ │ │ │┄ Files differ │ ├── data.tar.xz │ │ ├── data.tar │ │ │ ├── file list │ │ │ │ @@ -2,15 +2,15 @@ │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2024-07-10 18:27:49.000000 ./usr/ │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2024-07-10 18:27:49.000000 ./usr/share/ │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2024-07-10 18:27:49.000000 ./usr/share/doc/ │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1227 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/changelog.Debian.gz │ │ │ │ -rw-r--r-- 0 root (0) root (0) 2807 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/copyright │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/ │ │ │ │ --rw-r--r-- 0 root (0) root (0) 18206 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/accessing-results.html │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 18203 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/accessing-results.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 80622 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/annotated.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 22035 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/annotated_dup.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 63246 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/array-composite_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 86939 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/array_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 674 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/bc_s.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 634 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/bc_sd.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 8304 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/binary.html │ │ │ │ @@ -385,15 +385,15 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 9688 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/connection-sql__cursor_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 8828 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/connection-stream__from_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 8758 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/connection-stream__to_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 14179 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/connection-transaction_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 128127 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/connection_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 257528 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/conversions_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 59526 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/cursor_8hxx_source.html │ │ │ │ --rw-r--r-- 0 root (0) root (0) 36018 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/datatypes.html │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 36023 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/datatypes.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 13979 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/dbtransaction_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 19448 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/deprecated.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 5220 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/dir_09456df80b5baeba1147d2b9ef5f002c.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 397 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/dir_09456df80b5baeba1147d2b9ef5f002c_dep.map │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1857 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/dir_09456df80b5baeba1147d2b9ef5f002c_dep.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 11099 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/dir_3abbb4e2076021b5d2239498be5fcb30.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1544 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/dir_3abbb4e2076021b5d2239498be5fcb30.js │ │ │ │ @@ -416,15 +416,15 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 45631 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/doxygen.css │ │ │ │ -rw-r--r-- 0 root (0) root (0) 15461 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/doxygen.svg │ │ │ │ -rw-r--r-- 0 root (0) root (0) 7704 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/dynsections.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 11900 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/encoding__group_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 137794 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/encodings_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 8272 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/errorhandler-connection_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 17748 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/errorhandler_8hxx_source.html │ │ │ │ --rw-r--r-- 0 root (0) root (0) 9569 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/escaping.html │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 9567 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/escaping.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 144139 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/except_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 81786 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/field_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 25190 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/files.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 223 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/files_dup.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1996 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/folderclosed.svg │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1996 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/folderclosedd.svg │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3269 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/folderopen.svg │ │ │ │ @@ -818,18 +818,18 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 168 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/nav_fd.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 95 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/nav_g.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 98 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/nav_h.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 111 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/nav_hd.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 2167 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtree.css │ │ │ │ -rw-r--r-- 0 root (0) root (0) 15935 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtree.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 5932 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreedata.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 19179 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex0.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 19176 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex0.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 21143 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex1.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 19444 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex2.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 15181 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex3.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 15184 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex3.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 18077 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex4.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 17723 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex5.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 271 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/navtreeindex6.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 13252 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/nontransaction_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 15955 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/notification_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 122 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/open.png │ │ │ │ -rw-r--r-- 0 root (0) root (0) 6420 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/pages.html │ │ │ │ @@ -852,37 +852,37 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 30983 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/result__iter_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 61623 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/result__iterator_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 19458 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/robusttransaction_8hxx_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 90886 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/row_8hxx_source.html │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 7418 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_0.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 4742 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_1.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 6981 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_10.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 21081 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_11.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 7490 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_12.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 2858 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_13.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 6978 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_10.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 21082 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_11.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 7495 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_12.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 2857 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_13.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 906 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_14.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 1395 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_15.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 1394 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_15.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 94 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_16.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1207 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_17.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 319 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_18.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 15180 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_2.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 4708 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_3.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 8728 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_4.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 4707 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_3.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 8727 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_4.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 6995 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_5.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 5455 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_6.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1038 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_7.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 5821 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_8.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 147 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_9.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 2861 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_a.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 1298 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_b.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 8911 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_c.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 8814 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_d.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 6212 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_e.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 4375 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_f.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 1297 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_b.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 8912 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_c.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 8813 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_d.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 6249 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_e.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 4374 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/all_f.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 875 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/classes_0.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1086 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/classes_1.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 975 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/classes_10.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 835 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/classes_11.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 157 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/classes_12.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 85 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/classes_13.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3820 2024-07-10 18:27:49.000000 ./usr/share/doc/libpqxx-doc/doxygen-html/search/classes_2.js │ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/accessing-results.html │ │ │ │ @@ -93,38 +93,38 @@ │ │ │ │
Accessing results and result rows
│ │ │ │ │ │ │ │
│ │ │ │

A query produces a result set consisting of rows, and each row consists of fields. There are several ways to receive this data.

│ │ │ │

The fields are "untyped." That is to say, libpqxx has no opinion on what their types are. The database sends the data in a very flexible textual format. When you read a field, you specify what type you want it to be, and libpqxx converts the text format to that type for you.

│ │ │ │

If a value does not conform to the format for the type you specify, the conversion fails. For example, if you have strings that all happen to contain numbers, you can read them as int. But if any of the values is empty, or it's null (for a type that doesn't support null), or it's some string that does not look like an integer, or it's too large, you can't convert it to int.

│ │ │ │

So usually, reading result data from the database means not just retrieving the data; it also means converting it to some target type.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Querying rows of data

│ │ │ │

The simplest way to query rows of data is to call one of a transaction's "query" functions, passing as template arguments the types of columns you want to get back (e.g. int, std::string, double, and so on) and as a regular argument the query itself.

│ │ │ │

You can then iterate over the result to go over the rows of data:

│ │ │ │
for (auto [id, value] :
│ │ │ │
tx.query<int, std::string>("SELECT id, name FROM item"))
│ │ │ │
{
│ │ │ │
std::cout << id << '\t' << value << '\n';
│ │ │ │
}
│ │ │ │

The "query" functions execute your query, load the complete result data from the database, and then as you iterate, convert each row it received to a tuple of C++ types that you indicated.

│ │ │ │

There are different query functions for querying any number of rows (query()); querying just one row of data as a std::tuple and throwing an error if there's more than one row (query1()); or querying

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Streaming rows

│ │ │ │

There's another way to go through the rows coming out of a query. It's usually easier and faster if there are a lot of rows, but there are drawbacks.

│ │ │ │

One, you start getting rows before all the data has come in from the database. That speeds things up, but what happens if you lose your network connection while transferring the data? Your application may already have processed some of the data before finding out that the rest isn't coming. If that is a problem for your application, streaming may not be the right choice.

│ │ │ │

Two, streaming only works for some types of query. The stream() function wraps your query in a PostgreSQL COPY command, and COPY only supports a few commands: SELECT, VALUES, or an INSERT, UPDATE, or DELETE with a RETURNING clause. See the COPY documentation here: [ https://www.postgresql.org/docs/current/sql-copy.html ](https://www.postgresql.org/docs/current/sql-copy.html).

│ │ │ │

Three, when you convert a field to a "view" type (such as std::string_view or pqxx::bytes_view), the view points to underlying data which only stays valid until you iterate to the next row or exit the loop. So if you want to use that data for longer than a single iteration of the streaming loop, you'll have to store it somewhere yourself.

│ │ │ │

Now for the good news. Streaming does make it very easy to query data and loop over it, and often faster than with the "query" or "exec" functions:

│ │ │ │
for (auto [id, name, x, y] :
│ │ │ │
tx.stream<int, std::string_view, float, float>(
│ │ │ │
"SELECT id, name, x, y FROM point"))
│ │ │ │
process(id + 1, "point-" + name, x * 10.0, y * 10.0);
│ │ │ │

The conversion to C++ types (here int, std::string_view, and two floats) is built into the function. You never even see row objects, field objects, iterators, or conversion methods. You just put in your query and you receive your data.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Results with metadata

│ │ │ │

Sometimes you want more from a query result than just rows of data. You may need to know right away how many rows of result data you received, or how many rows your UPDATE statement has affected, or the names of the columns, etc.

│ │ │ │

For that, use the transaction's "exec" query execution functions. Apart from a few exceptions, these return a pqxx::result object. A result is a container of pqxx::row objects, so you can iterate them as normal, or index them like you would index an array. Each row in turn is a container of pqxx::field, Each field holds a value, but doesn't know its type. You specify the type when you read the value.

│ │ │ │

For example, your code might do:

│ │ │ │
pqxx::result r = tx.exec("SELECT * FROM mytable");
│ │ │ │
for (auto const &row: r)
│ │ │ │
{
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/binary.html │ │ │ │ @@ -103,15 +103,15 @@ │ │ │ │
std::string hi{"Hello binary world"};
│ │ │ │
my_blob.write(pqxx::binary_cast(hi);
│ │ │ │
pqxx::binary_cast
bytes_view binary_cast(TYPE const &data)
Cast binary data to a type that libpqxx will recognise as binary.
Definition util.hxx:409
│ │ │ │

The other takes a pointer and a size:

│ │ │ │
char const greeting[] = "Hello binary world";
│ │ │ │
char const *hi = greeting;
│ │ │ │
my_blob.write(pqxx::binary_cast(hi, sizeof(greeting)));
│ │ │ │ -

│ │ │ │ +

│ │ │ │ Caveats

│ │ │ │

There are some restrictions on binary_cast that you must be aware of.

│ │ │ │

First, your data must of a type that gives us bytes. So: char, unsigned char, signed char, int8_t, uint8_t, or of course std::byte. You can't feed in a vector of double, or anything like that.

│ │ │ │

Second, the data must be laid out as a contiguous block in memory. If there's no std::data() implementation for your type, it's not suitable.

│ │ │ │

Third, binary_cast only constructs something like a std::string_view. It does not make a copy of your actual data. So, make sure that your data remains alive and in the same place while you're using it.

│ │ │ │
│ │ │ │ │ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1basic__ilostream.html │ │ │ │ @@ -151,15 +151,15 @@ │ │ │ │  basic_ilostream (dbtransaction &t, oid o, largeobject::size_type buf_size=512) │ │ │ │  Create a basic_ilostream.
│ │ │ │   │ │ │ │ │ │ │ │

Detailed Description

│ │ │ │
template<typename CHAR = char, typename TRAITS = std::char_traits<CHAR>>
│ │ │ │ class pqxx::basic_ilostream< CHAR, TRAITS >

Input stream that gets its data from a large object.

│ │ │ │ -
Deprecated:
Access large objects directly using the blob class.
│ │ │ │ +
Deprecated:
Access large objects directly using the blob class.
│ │ │ │

This class worked like any other istream, but to read data from a large object. It supported all formatting and streaming operations of std::istream.

│ │ │ │

This functionality was considered too fragile and complex, so it has been replaced with a single, much simpler class.

│ │ │ │

Constructor & Destructor Documentation

│ │ │ │ │ │ │ │

◆ basic_ilostream() [1/2]

│ │ │ │ │ │ │ │
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1basic__lostream.html │ │ │ │ @@ -151,15 +151,15 @@ │ │ │ │  basic_lostream (dbtransaction &t, oid o, largeobject::size_type buf_size=512) │ │ │ │  Create a basic_lostream.
│ │ │ │   │ │ │ │ │ │ │ │

Detailed Description

│ │ │ │
template<typename CHAR = char, typename TRAITS = std::char_traits<CHAR>>
│ │ │ │ class pqxx::basic_lostream< CHAR, TRAITS >

Stream that reads and writes a large object.

│ │ │ │ -
Deprecated:
Access large objects directly using the blob class.
│ │ │ │ +
Deprecated:
Access large objects directly using the blob class.
│ │ │ │

This worked like a std::iostream, but to read data from, or write data to, a large object. It supported all formatting and streaming operations of std::iostream.

│ │ │ │

This functionality was considered too fragile and complex, so it has been replaced with a single, much simpler class.

│ │ │ │

Constructor & Destructor Documentation

│ │ │ │ │ │ │ │

◆ basic_lostream() [1/2]

│ │ │ │ │ │ │ │
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1basic__olostream.html │ │ │ │ @@ -151,15 +151,15 @@ │ │ │ │  basic_olostream (dbtransaction &t, oid o, largeobject::size_type buf_size=512) │ │ │ │  Create a basic_olostream.
│ │ │ │   │ │ │ │ │ │ │ │

Detailed Description

│ │ │ │
template<typename CHAR = char, typename TRAITS = std::char_traits<CHAR>>
│ │ │ │ class pqxx::basic_olostream< CHAR, TRAITS >

Output stream that writes data back to a large object.

│ │ │ │ -
Deprecated:
Access large objects directly using the blob class.
│ │ │ │ +
Deprecated:
Access large objects directly using the blob class.
│ │ │ │

This worked like any other ostream, but to write data to a large object. It supported all formatting and streaming operations of std::ostream.

│ │ │ │

This functionality was considered too fragile and complex, so it has been replaced with a single, much simpler class.

│ │ │ │

Constructor & Destructor Documentation

│ │ │ │ │ │ │ │

◆ basic_olostream() [1/2]

│ │ │ │ │ │ │ │
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1largeobject.html │ │ │ │ @@ -171,15 +171,15 @@ │ │ │ │   │ │ │ │ │ │ │ │ PQXX_PRIVATE std::string reason (connection const &, int err) const │ │ │ │   │ │ │ │ │ │ │ │

Detailed Description

│ │ │ │

Identity of a large object.

│ │ │ │ -
Deprecated:
Use the blob class instead.
│ │ │ │ +
Deprecated:
Use the blob class instead.
│ │ │ │

Encapsulates the identity of a large object.

│ │ │ │

A largeobject must be accessed only from within a backend transaction, but the object's identity remains valid as long as the object exists.

│ │ │ │

Constructor & Destructor Documentation

│ │ │ │ │ │ │ │

◆ largeobject() [1/5]

│ │ │ │ │ │ │ │
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1largeobject__streambuf.html │ │ │ │ @@ -190,15 +190,15 @@ │ │ │ │ │ │ │ │ virtual int_type underflow () override │ │ │ │   │ │ │ │ │ │ │ │

Detailed Description

│ │ │ │
template<typename CHAR = char, typename TRAITS = std::char_traits<CHAR>>
│ │ │ │ class pqxx::largeobject_streambuf< CHAR, TRAITS >

Streambuf to use large objects in standard I/O streams.

│ │ │ │ -
Deprecated:
Access large objects directly using the blob class.
│ │ │ │ +
Deprecated:
Access large objects directly using the blob class.
│ │ │ │

The standard streambuf classes provide uniform access to data storage such as files or string buffers, so they can be accessed using standard input or output streams. This streambuf implementation provided similar access to large objects, so they could be read and written using the same stream classes.

│ │ │ │

This functionality was considered too fragile and complex, so it has been replaced with a single, much simpler class.

│ │ │ │

Member Data Documentation

│ │ │ │ │ │ │ │

◆ default_mode

│ │ │ │ │ │ │ │
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1largeobjectaccess.html │ │ │ │ @@ -238,15 +238,15 @@ │ │ │ │   │ │ │ │ bool operator>= (largeobject const &other) const │ │ │ │  Compare object identities.
│ │ │ │   │ │ │ │ │ │ │ │

Detailed Description

│ │ │ │

Accessor for large object's contents.

│ │ │ │ -
Deprecated:
Use the blob class instead.
│ │ │ │ +
Deprecated:
Use the blob class instead.
│ │ │ │

Member Typedef Documentation

│ │ │ │ │ │ │ │

◆ openmode

│ │ │ │ │ │ │ │
│ │ │ │
│ │ │ │ │ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1row.html │ │ │ │ @@ -497,15 +497,15 @@ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
) const
│ │ │ │
│ │ │ │

Produce a slice of this row, containing the given range of columns.

│ │ │ │ -
Deprecated:
I haven't heard of anyone caring about row slicing at all in at least the last 15 years. Yet it adds complexity, so unless anyone files a bug explaining why they really need this feature, I'm going to remove it. Even if they do, the feature may need an update.
│ │ │ │ +
Deprecated:
I haven't heard of anyone caring about row slicing at all in at least the last 15 years. Yet it adds complexity, so unless anyone files a bug explaining why they really need this feature, I'm going to remove it. Even if they do, the feature may need an update.
│ │ │ │

The slice runs from the range's starting column to the range's end column, exclusive. It looks just like a normal result row, except slices can be empty.

│ │ │ │ │ │ │ │
│ │ │ │
│ │ │ │ │ │ │ │

◆ table_column()

│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1stream__from.html │ │ │ │ @@ -209,15 +209,15 @@ │ │ │ │   │ │ │ │ static stream_from table (transaction_base &tx, table_path path, std::initializer_list< std::string_view > columns={}) │ │ │ │  Factory: Stream data from a given table.
│ │ │ │   │ │ │ │ │ │ │ │

Detailed Description

│ │ │ │

Stream data from the database.

│ │ │ │ -
Deprecated:
Use transaction_base::stream.
│ │ │ │ +
Deprecated:
Use transaction_base::stream.
│ │ │ │

For larger data sets, retrieving data this way is likely to be faster than executing a query and then iterating and converting the rows fields. You will also be able to start processing before all of the data has come in.

│ │ │ │

There are also downsides. Not all kinds of query will work in a stream. But straightforward SELECT and UPDATE ... RETURNING queries should work. This function makes use of pqxx::stream_from, which in turn uses PostgreSQL's COPY command, so see the documentation for those to get the full details.

│ │ │ │

There are other downsides. If there stream encounters an error, it may leave the entire connection in an unusable state, so you'll have to give the whole thing up. Finally, opening a stream puts the connection in a special state, so you won't be able to do many other things with the connection or the transaction while the stream is open.

│ │ │ │

There are two ways of starting a stream: you stream either all rows in a table (using one of the factories, table() or raw_table()), or the results of a query (using the query() factory).

│ │ │ │

Usually you'll want the stream convenience wrapper in transaction_base, * so you don't need to deal with this class directly.

│ │ │ │
Warning
While a stream is active, you cannot execute queries, open a pipeline, etc. on the same transaction. A transaction can have at most one object of a type derived from pqxx::transaction_focus active on it at a time.
│ │ │ │

Constructor & Destructor Documentation

│ │ │ │ @@ -250,15 +250,15 @@ │ │ │ │ ) │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │

Execute query, and stream over the results.

│ │ │ │ -
Deprecated:
Use factory function query instead.
│ │ │ │ +
Deprecated:
Use factory function query instead.
│ │ │ │ │ │ │ │
│ │ │ │
│ │ │ │ │ │ │ │

◆ stream_from() [2/7]

│ │ │ │ │ │ │ │
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/classpqxx_1_1stream__to.html │ │ │ │ @@ -222,15 +222,15 @@ │ │ │ │ │ │ │ │ inline │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │

Create a stream, without specifying columns.

│ │ │ │ -
Deprecated:
Use table or raw_table as a factory.
│ │ │ │ +
Deprecated:
Use table or raw_table as a factory.
│ │ │ │

Fields will be inserted in whatever order the columns have in the database.

│ │ │ │

You'll probably want to specify the columns, so that the mapping between your data fields and the table is explicit in your code, and not hidden in an "implicit contract" between your code and your schema.

│ │ │ │ │ │ │ │
│ │ │ │
│ │ │ │ │ │ │ │

◆ stream_to() [2/3]

│ │ │ │ @@ -271,15 +271,15 @@ │ │ │ │ │ │ │ │ inline │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │

Create a stream, specifying column names as a container of strings.

│ │ │ │ -
Deprecated:
Use table or raw_table as a factory.
│ │ │ │ +
Deprecated:
Use table or raw_table as a factory.
│ │ │ │ │ │ │ │
│ │ │ │
│ │ │ │ │ │ │ │

◆ stream_to() [3/3]

│ │ │ │ │ │ │ │
│ │ │ │ @@ -324,15 +324,15 @@ │ │ │ │ │ │ │ │ inline │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │

Create a stream, specifying column names as a sequence of strings.

│ │ │ │ -
Deprecated:
Use table or raw_table as a factory.
│ │ │ │ +
Deprecated:
Use table or raw_table as a factory.
│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │

Member Function Documentation

│ │ │ │ │ │ │ │

◆ complete()

│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/datatypes.html │ │ │ │ @@ -93,52 +93,52 @@ │ │ │ │
Supporting additional data types
│ │ │ │ │ │ │ │
│ │ │ │

Communication with the database mostly happens in a text format. When you include an integer value in a query, either you use to_string to convert it to that text format, or under the bonnet, libpqxx does it for you. When you get a query result field "as a float," libpqxx converts from the text format to a floating-point type. These conversions are everywhere in libpqxx.

│ │ │ │

The conversion system supports many built-in types, but it is also extensible. You can "teach" libpqxx (in the scope of your own application) to convert additional types of values to and from PostgreSQL's string format.

│ │ │ │

This is massively useful, but it's not for the faint of heart. You'll need to specialise some templates. And, the API for doing this can change with any major libpqxx release.

│ │ │ │

If that happens, your code may fail to compile with the newer libpqxx version, and you'll have to go through the NEWS file to find the API changes. Usually it'll be a small change, like an additional function you need to implement, or a constant you need to define.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Converting types

│ │ │ │

In your application, a conversion is driven entirely by a C++ type you specify. The value's SQL type on the database side has nothing to do with it. Nor is there anything in the string that would identify its type. Your code says "convert to this type" and libpqxx does it.

│ │ │ │

So, if you've SELECTed a 64-bit integer from the database, and you try to convert it to a C++ short, one of two things will happen: either the number is small enough to fit in your short and it just works, or else it throws a conversion exception. Similarly, if you try to read a 32-bit SQL int as a C++ 32-bit unsigned int, that'll work fine, unless the value happens to be negative. In such cases the conversion will throw a conversion_error.

│ │ │ │

Or, your database table might have a text column, but a given field may contain a string that looks just like a number. You can convert that value to an integer type just fine. Or to a floating-point type. All that matters to the conversion is the actual value, and the type your code specifies.

│ │ │ │

In some cases the templates for these conversions can tell the type from the arguments you pass them:

│ │ │ │
auto x = to_string(99);
│ │ │ │

In other cases you may need to instantiate template explicitly:

│ │ │ │
auto y = from_string<int>("99");
│ │ │ │ -

│ │ │ │ +

│ │ │ │ Supporting a new type

│ │ │ │

Let's say you have some other SQL type which you want to be able to store in, or retrieve from, the database. What would it take to support that?

│ │ │ │

Sometimes you do not need complete support. You might need a conversion to a string but not from a string, for example. You write out the conversion at compile time, so don't be too afraid to be incomplete. If you leave out one of these steps, it's not going to crash at run time or mess up your data. The worst that can happen is that your code won't build.

│ │ │ │

So what do you need for a complete conversion?

│ │ │ │

First off, of course, you need a C++ type. It may be your own, but it doesn't have to be. It could be a type from a third-party library, or even one from the standard library that libpqxx does not yet support.

│ │ │ │

First thing to do is specialise the pqxx::type_name variable to give the type a human-readable name. That allows libpqxx error messages and such to talk about the type. If you don't define a name, libpqxx will try to figure one out with some help from the compiler, but it may not always be easy to read.

│ │ │ │

Then, does your type have a built-in null value? For example, a char * can be null on the C++ side. Or some types are always null, such as nullptr. You specialise the pqxx::nullness template to specify the details.

│ │ │ │

Finally, you specialise the pqxx::string_traits template. This is where you define the actual conversions.

│ │ │ │

Let's go through these steps one by one.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Your type

│ │ │ │

You'll need a type for which the conversions are not yet defined, because the C++ type is what determines the right conversion. One type, one set of conversions.

│ │ │ │

The type doesn't have to be one that you create. The conversion logic was designed such that you can build it around any type. So you can just as easily build a conversion for a type that's defined somewhere else. There's no need to include any special methods or other members inside the type itself. That's also why libpqxx can convert built-in types like int.

│ │ │ │

By the way, if the type is an enum, you don't need to do any of this. Just invoke the preprocessor macro PQXX_DECLARE_ENUM_CONVERSION, from the global namespace near the top of your translation unit, and pass the type as an argument.

│ │ │ │

The library also provides specialisations for std::optional<T>, std::shared_ptr<T>, and std::unique_ptr<T>. If you have conversions for T, you'll also automatically have conversions for those.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Specialise <tt>type_name</tt>

│ │ │ │

When errors happen during conversion, libpqxx will compose error messages for the user. Sometimes these will include the name of the type that's being converted.

│ │ │ │

To tell libpqxx the name of each type, there's a template variable called pqxx::type_name. For any given type T, it should have a specialisation that provides that T's human-readable name:

│ │ │ │
// T is your type.
│ │ │ │
namespace pqxx
│ │ │ │
{
│ │ │ │
template<> std::string const type_name<T>{"My T type's name"};
│ │ │ │
}
│ │ │ │
pqxx
The home of all libpqxx classes, functions, templates, etc.
Definition array.cxx:27
│ │ │ │

(Yes, this means that you need to define something inside the pqxx namespace. Future versions of libpqxx may move this into a separate namespace.)

│ │ │ │

Define this early on in your translation unit, before any code that might cause libpqxx to need the name. That way, the libpqxx code which needs to know the type's name can see your definition.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Specialise <tt>nullness</tt>

│ │ │ │

A struct template pqxx::nullness defines whether your type has a natural "null value" built in. If so, it also provides member functions for producing and recognising null values.

│ │ │ │

The simplest scenario is also the most common: most types don't have a null value built in. There is no "null `int`" in C++. In that kind of case, just derive your nullness traits from pqxx::no_null as a shorthand:

│ │ │ │
// T is your type.
│ │ │ │
namespace pqxx
│ │ │ │
{
│ │ │ │
template<> struct nullness<T> : pqxx::no_null<T> {};
│ │ │ │ @@ -172,15 +172,15 @@ │ │ │ │
}
│ │ │ │
pqxx::nullness::is_null
static bool is_null(TYPE const &value)
Is value a null?
│ │ │ │
pqxx::nullness::null
static TYPE null()
Return a null value.
│ │ │ │
pqxx::nullness::has_null
static bool has_null
Does this type have a null value?
Definition strconv.hxx:93
│ │ │ │
pqxx::nullness::always_null
static bool always_null
Is this type always null?
Definition strconv.hxx:96
│ │ │ │

You may be wondering why there's a function to produce a null value, but also a function to check whether a value is null. Why not just compare the value to the result of null()? Because two null values may not be equal (like in SQL, where NULL <> NULL). Or T may have multiple different null values. Or T may override the comparison operator to behave in some unusual way.

│ │ │ │

As a third case, your type may be one that always represents a null value. This is the case for std::nullptr_t and std::nullopt_t. In that case, you set nullness<TYPE>::always_null to true (as well as has_null of course), and you won't need to define any actual conversions.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Specialise <tt>string_traits</tt>

│ │ │ │

This part is the most work. You can skip it for types that are always null, but those will be rare.

│ │ │ │

The APIs for doing this are designed so that you don't need to allocate memory on the free store, also known as "the heap": new/delete. Memory allocation can be hidden inside std::string, std::vector, etc. The conversion API allows you to use std::string for convenience, or memory buffers for speed.

│ │ │ │

Start by specialising the pqxx::string_traits template. You don't absolutely have to implement all parts of this API. Generally, if it compilers, you're OK for the time being. Just bear in mind that future libpqxx versions may change the API — or how it uses the API internally.

│ │ │ │
namespace pqxx
│ │ │ │
{
│ │ │ │
// T is your type.
│ │ │ │ @@ -211,22 +211,22 @@ │ │ │ │
pqxx::string_traits::from_string
static TYPE from_string(std::string_view text)
Parse a string representation of a TYPE value.
│ │ │ │
pqxx::string_traits::size_buffer
static std::size_t size_buffer(TYPE const &value) noexcept
Estimate how much buffer space is needed to represent value.
│ │ │ │
pqxx::string_traits::to_buf
static zview to_buf(char *begin, char *end, TYPE const &value)
Return a string_view representing value, plus terminating zero.
│ │ │ │
pqxx::string_traits::converts_to_string
static constexpr bool converts_to_string
Is conversion from TYPE to strings supported?
Definition strconv.hxx:158
│ │ │ │
pqxx::string_traits::into_buf
static char * into_buf(char *begin, char *end, TYPE const &value)
Write value's string representation into buffer at begin.
│ │ │ │
pqxx::string_traits::converts_from_string
static constexpr bool converts_from_string
Is conversion from string_view to TYPE supported?
Definition strconv.hxx:164
│ │ │ │

You'll also need to write those member functions, or as many of them as needed to get your code to build.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ <tt>from_string</tt>

│ │ │ │

We start off simple: from_string parses a string as a value of T, and returns that value.

│ │ │ │

The string may or may not be zero-terminated; it's just the string_view from beginning to end (with end being exclusive). In your tests, be sure to cover cases where the string does not end in a zero byte!

│ │ │ │

It's perfectly possible that the string doesn't actually represent a T value. Mistakes happen. There can be corner cases. When you run into this, throw a pqxx::conversion_error.

│ │ │ │

(Of course it's also possible that you run into some other error, so it's fine to throw different exceptions as well. But when it's definitely "this is not │ │ │ │ the right format for a `T`," throw conversion_error.)

│ │ │ │ -

│ │ │ │ +

│ │ │ │ <tt>to_buf</tt>

│ │ │ │

In this function, you convert a value of T into a string that the postgres server will understand.

│ │ │ │

The caller will provide you with a buffer where you can write the string, if you need it: from begin to end exclusive. It's a half-open interval, so don't access *end.

│ │ │ │

If the buffer is insufficient for you to do the conversion, throw a pqxx::conversion_overrun. It doesn't have to be exact: you can be a little pessimistic and demand a bit more space than you need. Just be sure to throw the exception if there's any risk of overrunning the buffer.

│ │ │ │

You don't have to use the buffer for this function though. For example, pqxx::string_traits<bool>::to_buf returns a compile-time constant string and completely ignores the buffer.

│ │ │ │

Even if you do use the buffer, your string does not have to start at the beginning of the buffer. For example, the integer conversions may work from right to left, if that's easier: they can start by writing the least significant digit to the end of the buffer, divide the remainder by 10, and repeat for the next digit.

│ │ │ │

Return a pqxx::zview. This is basically a std::string_view, but with one difference: when you create a zview you guarantee that there is a valid zero byte right after the string_view. The zero byte does not count as part of its size, but it has to be there.

│ │ │ │ @@ -234,36 +234,36 @@ │ │ │ │
void invariant(zview z)
│ │ │ │
{
│ │ │ │
assert(z[std::size(z)] == 0);
│ │ │ │
}
│ │ │ │

The trailing zero should not go inside the zview, but if you convert into the buffer, do make sure you that trailing stays inside the buffer, i.e. before the end. (If there's no room for that zero inside the buffer, throw pqxx::conversion_error).

│ │ │ │

Beware of locales when converting. If you use standard library features like sprintf, they may obey whatever locale is currently set on the system where the code runs. That means that a simple integer like 1000000 may come out as "1000000" on your system, but as "1,000,000" on mine, or as "1.000.000" for somebody else, and on an Indian system it may be "1,00,000". Don't let that happen, or it will confuse things. Use only non-locale-sensitive library functions. Values coming from or going to the database should be in fixed, non-localised formats.

│ │ │ │

If your conversions need to deal with fields in types that libpqxx already supports, you can use the conversion functions for those: pqxx::from_string, pqxx::to_string, pqxx::to_buf. They in turn will call the string_traits specialisations for those types. Or, you can call their string_traits directly.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ <tt>into_buf</tt>

│ │ │ │

This is a stricter version of to_buf. All the same requirements apply, but in addition you must write your string into the given buffer, starting exactly at begin.

│ │ │ │

That's why this function returns just a simple pointer: the address right behind the trailing zero. If the caller wants to use the string, they can find it at begin. If they want to write another value into the rest of the buffer, they can continue writing at the location you returned.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ <tt>size_buffer</tt>

│ │ │ │

Here you estimate how much buffer space you need for converting a T to a string. Be precise if you can, but pessimistic if you must. It's usually better to waste a few bytes of space than to spend a lot of time computing the exact buffer space you need. And failing the conversion because you under-budgeted the buffer is worst of all.

│ │ │ │

Include the trailing zero in the buffer size. If your to_buf takes more space than just what's needed to store the result, include that too.

│ │ │ │

Make size_buffer a constexpr function if you can. It can allow the caller to allocate the buffer on the stack, with a size known at compile time.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Optional: Specialise <tt>is_unquoted_safe</tt>

│ │ │ │

When converting arrays or composite values to strings, libpqxx may need to quote values and escape any special characters. This takes time.

│ │ │ │

Some types though, such as integral or floating-point types, can never have any special characters such as quotes, commas, or backslashes in their string representations. In such cases, there's no need to quote or escape such values in SQL arrays or composite types.

│ │ │ │

If your type is like that, you can tell libpqxx about this by defining:

│ │ │ │
namespace pqxx
│ │ │ │
{
│ │ │ │
// T is your type.
│ │ │ │
template<> inline constexpr bool is_unquoted_safe<T>{true};
│ │ │ │
}
│ │ │ │

The code that converts this type of field to strings in an array or a composite type can then use a simpler, more efficient variant of the code. It's always safe to leave this out; it's just an optimisation for when you're completely sure that it's safe.

│ │ │ │

Do not do this if a string representation of your type may contain a comma; semicolon; parenthesis; brace; quote; backslash; newline; or any other character that might need escaping.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Optional: Specialise <tt>param_format</tt>

│ │ │ │

This one you don't generally need to worry about. Read on if you're writing a type which represents raw binary data, or if you're writing a template where some specialisations may contain raw binary data.

│ │ │ │

When you call parameterised statements, or prepared statements with parameters, libpqxx needs to pass your parameters on to libpq, the underlying C-level PostgreSQL client library.

│ │ │ │

There are two formats for doing that: text and binary. In the first, we represent all values as strings in the PostgreSQL text format, and the server then converts them into its own internal binary representation. That's what those string conversions above are all about, and it's what we do for almost all types of parameters.

│ │ │ │

But we do it differently when the parameter is a contiguous series of raw bytes and the corresponding SQL type is BYTEA. There is a text format for those, but we bypass it for efficiency. The server can use the binary data in the exact same form, without any conversion or extra processing. The binary data is also twice as compact during transport.

│ │ │ │

(People sometimes ask why we can't just treat all types as binary. However the general case isn't so clear-cut. The binary formats are not documented, there are no guarantees that they will be platform-independent or that they will remain stable across postgres releases, and there's no really solid way to detect when we might get the format wrong. On top of all that, the conversions aren't necessarily as straightforward and efficient as they sound. So, for the general case, libpqxx sticks with the text formats. Raw binary data alone stands out as a clear win.)

│ │ │ │

Long story short, the machinery for passing parameters needs to know: is this parameter a binary string, or not? In the normal case it can assume "no," and that's what it does. The text format is always a safe choice; we just try to use the binary format where it's faster.

│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/deprecated.html │ │ │ │ @@ -93,19 +93,19 @@ │ │ │ │
Deprecated List
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
Class pqxx::basic_fieldstream< CHAR, TRAITS >
│ │ │ │
To convert a field's value string to some other type, e.g. to an int, use the field's as<...>() member function. To read a field efficiently just as a string, use its c_str() or its as<std::string_vview>().
│ │ │ │
Class pqxx::basic_ilostream< CHAR, TRAITS >
│ │ │ │ -
Access large objects directly using the blob class.
│ │ │ │ -
Class pqxx::basic_lostream< CHAR, TRAITS >
│ │ │ │
Access large objects directly using the blob class.
│ │ │ │ +
Class pqxx::basic_lostream< CHAR, TRAITS >
│ │ │ │ +
Access large objects directly using the blob class.
│ │ │ │
Class pqxx::basic_olostream< CHAR, TRAITS >
│ │ │ │ -
Access large objects directly using the blob class.
│ │ │ │ +
Access large objects directly using the blob class.
│ │ │ │
Class pqxx::binarystring
│ │ │ │
Use bytes and bytes_view for binary data. In C++20 or better, any contiguous_range of std::byte will do.
│ │ │ │
Member pqxx::blob::read (std::vector< std::byte, ALLOC > &buf)
│ │ │ │
As libpqxx moves to C++20 as its baseline language version, this will take and return std::span<std::byte>.
│ │ │ │
Member pqxx::connection::set_variable (std::string_view var, std::string_view value) &
│ │ │ │
To set a session variable, use set_session_var. To set a transaction-local variable, execute an SQL SET command.
│ │ │ │
Member pqxx::connection_base
│ │ │ │ @@ -113,59 +113,59 @@ │ │ │ │
Member pqxx::encrypt_password (char const user[], char const password[])
│ │ │ │
Use connection::encrypt_password instead.
│ │ │ │
Member pqxx::encrypt_password (zview user, zview password)
│ │ │ │
Use connection::encrypt_password instead.
│ │ │ │
Member pqxx::fieldstream
│ │ │ │
Read a field using field::as<...>() or field::c_str().
│ │ │ │
Member pqxx::from_query
│ │ │ │ -
Use transaction_base::stream instead of stream_from.
│ │ │ │ +
Use transaction_base::stream instead of stream_from.
│ │ │ │
Struct pqxx::from_query_t
│ │ │ │
Use stream_from::query() instead.
│ │ │ │
Member pqxx::from_table
│ │ │ │ -
Use transaction_base::stream instead of stream_from.
│ │ │ │ +
Use transaction_base::stream instead of stream_from.
│ │ │ │
Struct pqxx::from_table_t
│ │ │ │
Use stream_from::table() instead.
│ │ │ │
Class pqxx::internal::dynamic_params< IT, ACCESSOR >
│ │ │ │
Use params instead.
│ │ │ │
Class pqxx::largeobject
│ │ │ │ -
Use the blob class instead.
│ │ │ │ +
Use the blob class instead.
│ │ │ │
Class pqxx::largeobject_streambuf< CHAR, TRAITS >
│ │ │ │ -
Access large objects directly using the blob class.
│ │ │ │ +
Access large objects directly using the blob class.
│ │ │ │
Class pqxx::largeobjectaccess
│ │ │ │ -
Use the blob class instead.
│ │ │ │ +
Use the blob class instead.
│ │ │ │
Member pqxx::operator<< (std::basic_ostream< CHAR > &s, field const &value)
│ │ │ │
The C++ streams library is not great to work with. In particular, error handling is easy to get wrong. So you're probably better off doing this by hand.
│ │ │ │
Member pqxx::params::append (binarystring const &value) &
│ │ │ │
Append binarystring parameter.
│ │ │ │
Namespace pqxx::prepare
│ │ │ │ -
The new params class replaces all of this.
│ │ │ │ +
The new params class replaces all of this.
│ │ │ │
Member pqxx::row::slice (size_type sbegin, size_type send) const
│ │ │ │ -
I haven't heard of anyone caring about row slicing at all in at least the last 15 years. Yet it adds complexity, so unless anyone files a bug explaining why they really need this feature, I'm going to remove it. Even if they do, the feature may need an update.
│ │ │ │ +
I haven't heard of anyone caring about row slicing at all in at least the last 15 years. Yet it adds complexity, so unless anyone files a bug explaining why they really need this feature, I'm going to remove it. Even if they do, the feature may need an update.
│ │ │ │
Class pqxx::stream_from
│ │ │ │ -
Use transaction_base::stream.
│ │ │ │ +
Use transaction_base::stream.
│ │ │ │
Member pqxx::stream_from::stream_from (transaction_base &, from_table_t, std::string_view table)
│ │ │ │
Use factories table or raw_table instead.
│ │ │ │
Member pqxx::stream_from::stream_from (transaction_base &, std::string_view table, Iter columns_begin, Iter columns_end)
│ │ │ │
Use factories table or raw_table instead.
│ │ │ │
Member pqxx::stream_from::stream_from (transaction_base &tx, std::string_view table, Columns const &columns)
│ │ │ │
Use factories table or raw_table instead.
│ │ │ │
Member pqxx::stream_from::stream_from (transaction_base &tx, std::string_view table)
│ │ │ │
Use factories table or raw_table instead.
│ │ │ │
Member pqxx::stream_from::stream_from (transaction_base &tx, from_table_t, std::string_view table, Columns const &columns)
│ │ │ │
Use factory function query instead.
│ │ │ │
Member pqxx::stream_from::stream_from (transaction_base &, from_table_t, std::string_view table, Iter columns_begin, Iter columns_end)
│ │ │ │
Use factories table or raw_table instead.
│ │ │ │
Member pqxx::stream_from::stream_from (transaction_base &, from_query_t, std::string_view query)
│ │ │ │ -
Use factory function query instead.
│ │ │ │ +
Use factory function query instead.
│ │ │ │
Member pqxx::stream_to::stream_to (transaction_base &tx, std::string_view table_name)
│ │ │ │ -
Use table or raw_table as a factory.
│ │ │ │ +
Use table or raw_table as a factory.
│ │ │ │
Member pqxx::stream_to::stream_to (transaction_base &, std::string_view table_name, Columns const &columns)
│ │ │ │ -
Use table or raw_table as a factory.
│ │ │ │ +
Use table or raw_table as a factory.
│ │ │ │
Member pqxx::stream_to::stream_to (transaction_base &, std::string_view table_name, Iter columns_begin, Iter columns_end)
│ │ │ │ -
Use table or raw_table as a factory.
│ │ │ │ +
Use table or raw_table as a factory.
│ │ │ │
Member pqxx::strip_t
│ │ │ │
In C++20 we'll replace this with std::remove_cvref.
│ │ │ │
Member pqxx::transaction_base::set_variable (std::string_view var, std::string_view value)
│ │ │ │
To set a transaction-local variable, execute an SQL SET command. To set a session variable, use the connection's set_session_var function.
│ │ │ │
│ │ │ │
│ │ │ │ │ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/escaping.html │ │ │ │ @@ -95,30 +95,30 @@ │ │ │ │
│ │ │ │

Writing queries as strings is easy. But sometimes you need a variable in there: ‘"SELECT id FROM user WHERE name = &rsquo;" + name + "'"`.

│ │ │ │

This is dangerous. See the bug? If name can contain quotes, you may have an SQL injection vulnerability there, where users can enter nasty stuff like "`.'; DROP TABLE user`". Or if you're lucky, it's just a nasty bug that you discover when name happens to be "d'Arcy". Or... Well, I was born in a place called _'s-Gravenhage..._

│ │ │ │

There are two ways of dealing with this. One is statement parameters: some SQL execution functions in libpqxx let you write placeholders for such values in your SQL, like $1, $2, etc. When you then pass your variables as the parameter values, they get substituted into the query, but in a safe form.

│ │ │ │

The other is to escape the values yourself, before inserting them into your SQL. This isn't as safe as using parameters, since you need to be really conscientious about it. Use parameters if you can... and libpqxx will do the escaping for you.

│ │ │ │

In escaping, quotes and other problematic characters are marked as "this is │ │ │ │ just a character inside the string, not the end of the string." There are several functions in libpqxx to do this for you.

│ │ │ │ -

│ │ │ │ +

│ │ │ │ SQL injection

│ │ │ │

To understand what SQL injection vulnerabilities are and why they should be prevented, imagine you use the following SQL statement somewhere in your program:

│ │ │ │
tx.exec(
│ │ │ │
"SELECT number, amount "
│ │ │ │
"FROM account "
│ │ │ │
"WHERE allowed_to_see('" + userid + "','" + password + "')");
│ │ │ │

This shows a logged-in user important information on all accounts he is authorized to view. The userid and password strings are variables entered by the user himself.

│ │ │ │

Now, if the user is actually an attacker who knows (or can guess) the general shape of this SQL statement, imagine getting following password:

│ │ │ │
x') OR ('x' = 'x
│ │ │ │

Does that make sense to you? Probably not. But if this is inserted into the SQL string by the C++ code above, the query becomes:

│ │ │ │
SELECT number, amount
│ │ │ │
FROM account
│ │ │ │
WHERE allowed_to_see('user','x') OR ('x' = 'x')
│ │ │ │

Is this what you wanted to happen? Probably not! The neat allowed_to_see() clause is completely circumvented by the "`OR ('x' = 'x')`" clause, which is always true. Therefore, the attacker will get to see all accounts in the database!

│ │ │ │ -

│ │ │ │ +

│ │ │ │ Using the esc functions

│ │ │ │

Here's how you can fix the problem in the example above:

│ │ │ │
tx.exec(
│ │ │ │
"SELECT number, amount "
│ │ │ │
"FROM account "
│ │ │ │
"WHERE allowed_to_see('" + tx.esc(userid) + "', "
│ │ │ │
"'" + tx.esc(password) + "')");
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/namespacepqxx.html │ │ │ │ @@ -1914,15 +1914,15 @@ │ │ │ │ │ │ │ │ constexpr │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │

Pass this to a stream_from constructor to stream query results.

│ │ │ │ -
Deprecated:
Use transaction_base::stream instead of stream_from.
│ │ │ │ +
Deprecated:
Use transaction_base::stream instead of stream_from.
│ │ │ │ │ │ │ │
│ │ │ │
│ │ │ │ │ │ │ │

◆ from_table

│ │ │ │ │ │ │ │
│ │ │ │ @@ -1939,15 +1939,15 @@ │ │ │ │ │ │ │ │ constexpr │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │

Pass this to a stream_from constructor to stream table contents.

│ │ │ │ -
Deprecated:
Use transaction_base::stream instead of stream_from.
│ │ │ │ +
Deprecated:
Use transaction_base::stream instead of stream_from.
│ │ │ │ │ │ │ │
│ │ │ │
│ │ │ │ │ │ │ │

◆ has_generic_bytes_char_traits

│ │ │ │ │ │ │ │
│ │ │ ├── ./usr/share/doc/libpqxx-doc/doxygen-html/namespacepqxx_1_1prepare.html │ │ │ │ @@ -90,15 +90,15 @@ │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │
pqxx::prepare Namespace Reference
│ │ │ │
│ │ │ │
│ │ │ │

Detailed Description

│ │ │ │ -
Deprecated:
The new params class replaces all of this.
│ │ │ │ +
Deprecated:
The new params class replaces all of this.
│ │ │ │
│ │ │ │
│ │ │ │ │ │ │ │