Version 0.59 of package Pg has just been released in NonGNU ELPA. You can now find it in M-x list-packages RET.
Pg describes itself as: ================================================= Socket-level interface to the PostgreSQL database ================================================= More at https://elpa.nongnu.org/nongnu/pg.html ## Summary: # pg.el -- Emacs Lisp socket-level interface to the PostgreSQL RDBMS ## Recent NEWS: # Changelog ## [0.59] - 2025-08-31 - Add detection code and workarounds for the Yellowbrick PostgreSQL variant. - Add support for parsing an `options` parameter in a connection string or connection URI, or for parsing the contents of the `PGOPTIONS` environment variable (as per the [libpq behaviour](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS)). This is an alternative to using elisp code on `pg-new-connection-hook`. - Fixes for serializing `bpchar` values when they are used by PostgreSQL to represent `CHAR(N)` fields (bug reported by @Tekki). - Change the mechanism used to send messages to PostgreSQL: instead of sending data incrementally we accumulate data in a per-connection output buffer and send it in a chunk when `pg-flush` is called. This should reduce the number of small fragmented network packets exchanged with the PostgreSQL backend, and should improve performance. ## [0.58] - 2025-08-13 - Add serialization support for the `numeric` data type, for arguments to prepared statements. - Add serialization support for homogeneous arrays when using the extended query protocol. Types such as `text[]` (known as `_text` in the `pg_type` system table), `int4[]`, `float4[]`, `float8[]` can now be passed as function arguments. - Fix parsing of the `bpchar` type, which PostgreSQL uses on the wire to represent `CHARACTER(N)` objects. These objects would previously be truncated to their first character, but are now parsed as a full length string if the length is greater than 1 character, and still as an Emacs Lisp character when the length is equal to 1. The returned string includes trailing padding spaces if the value inserted is less long than the field width. Bug reported by @Tekki. - Add serialization support for the `_varchar` data type. - Add parsing and serialization support for the `_uuid` data type. - Add workarounds and detection code for the CedarDB PostgreSQL variant. - New error classes `pg-duplicate-table` and `pg-duplicate-column`, subclasses of `pg-programming-error`. - New error class `pg-sequence-limit-exceeded`, a subclass of `pg-data-error`. ## [0.57] - 2025-07-30 - Fix the large object functionality to work with version 3 of the frontend-backend wire protocol. The large object functions use the 64-bit versions of the backend functions (`lo_lseek64`, `lo_truncate64` etc.) to support interactions with large objects up to 4TB in size. ## [0.56] - 2025-07-20 - Allow for two successive messages of type `ErrorMessage` (which is unusual, but used by the OctoDB variant). - Detect and implement workarounds for the semi-compatible PostgreSQL variants Vertica, PolarDB, and ArcadeDB, and the graph processing extension AgensGraph. ## [0.55] - 2025-06-29 - New error class `pg-duplicate-prepared-statement`. - New function `pg-connect/direct-tls` to establish a direct TLS connection to PostgreSQL, rather than the STARTTLS-like method used in the standard wire protocol. This connection method is implemented from PostgreSQL v18 (currently in beta). It requires ALPN support in Emacs, which is not yet committed. - The `pg-sync` function tries a little harder to resynchronize the data stream with the backend, by reading and discarding additional message types that cannot lead to data loss. - Recognize the hosted PostgreSQL provider thenile.dev as variant `thenile` and implement some workarounds for its limitations. ## [0.54] - 2025-05-03 - Handle `ParameterStatus` and `NotificationResponse` messages in `pg-fetch`. - New function `pg-set-client-encoding` to set the client-side encoding for data sent to the backend. Calling this function sends an SQL request to the backend telling it of the new client encoding, and sets the per-connection client encoding (accessible via `pgcon-client-encoding`). It also checks that the requested client encoding is one supported by PostgreSQL. Note that most of the PostgreSQL variants only support UTF8 as a client-encoding. ... ...
