Version 0.58 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.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. - Implement workaround for `pg-column-default` for Google Spanner and QuestDB. - Fix for parsing empty arrays. - New subclass of `pg-error` `pg-transaction-missing` triggered by an attempt to rollback with no transaction in progress. - Add preliminary support for the ReadySet PostgreSQL proxy as a PostgreSQL variant. - Add preliminary support for the YottaDB Octo database as a PostgreSQL variant. ## [0.53] - 2025-04-19 - In `pg-sync`, try to read the `ReadyForQuery` message sent by the backend. - Add test code for the PgDog and PgCat sharding connection poolers. - Implement workarounds for the RisingWave variant in `pg-table-comment` and `pg-column-comment` and their companion setf functions. - Populate our oid<->typname mappings with predefined data for variants that lack a properly populated `pg_type` table (this is the case for GreptimeDB, which contains invalud information such as `UInt8` ... ...
