branch: elpa/pg
commit 1ec78d52651468613e129e2332d204fb9ad91d76
Author: Eric Marsden <eric.mars...@risk-engineering.org>
Commit: Eric Marsden <eric.mars...@risk-engineering.org>
Update information on tested versions of PostgreSQL variants
---
README.md | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/README.md b/README.md
index 8cf2f5b20ea..8b113a03bf0 100644
--- a/README.md
+++ b/README.md
@@ -73,7 +73,7 @@ The following PostgreSQL-compatible databases or extensions
have been tested:
extension rather than a distinct database implementation).
- [IvorySQL](https://www.ivorysql.org/) works perfectly (this Apache licensed
fork of PostgreSQL
- adds some features for compatibility with Oracle). Last tested 2025-04 with
version 4.4.
+ adds some features for compatibility with Oracle). Last tested 2025-08 with
version 4.5.
- The [Timescale DB](https://www.timescale.com/) extension for time series
data, source available
but non open source. This works perfectly (last tested 2025-08 with version
2.19.3).
@@ -98,6 +98,9 @@ The following PostgreSQL-compatible databases or extensions
have been tested:
- The [PgBouncer](https://www.pgbouncer.org/) connection pooler for PostgreSQL
(open source, ISC
licensed). Works fine (last tested 2025-08 with version 1.24 in the default
session pooling mode).
+- The [Odyssey](https://github.com/yandex/odyssey) connection pooler from
Yandex (BSD license) works
+ perfectly with pg-el (last tested 2025-08 with version 1.4.0 in session
pooling mode).
+
- The [PgDog](https://github.com/pgdogdev/pgdog) sharding connection pooler
for PostgreSQL (AGPLv3
licensed). We encounter some errors when using the extended query protocol:
unnamed prepared
statements and prepared statments named `__pgdog_N` are reported not to
exist. The pooler also
@@ -143,7 +146,7 @@ The following PostgreSQL-compatible databases or extensions
have been tested:
functionality, and its interpretation of SQL occasionally differs from that
of PostgreSQL.
Currently fails with an internal error on the SQL generated by our query for
`pg-table-owner`, and
fails on the boolean vector syntax b'1001000'. Works with these limitations
with pg-el (last
- tested 2025-08 with CockroachDB CCL v25.2).
+ tested 2025-08 with CockroachDB CCL v25.3).
- The [YDB by Yandex](https://ydb.tech/docs/en/postgresql/docker-connect)
distributed database
(Apache licence). Has very limited PostgreSQL compatibility. For example, an
empty query string
@@ -153,7 +156,7 @@ The following PostgreSQL-compatible databases or extensions
have been tested:
- The [Materialize](https://materialize.com/) operational database (a
proprietary differential
dataflow database) has many limitations in its PostgreSQL compatibility: no
support for primary
keys, unique constraints, check constraints, for the `bit` type for example.
It works with these
- limitations with pg-el (last tested 2025-08 with Materialize v0.153).
+ limitations with pg-el (last tested 2025-08 with Materialize v0.154).
- The [CedarDB](https://cedardb.com/) database spun off from the Umbra
research database developed
at the University of Munich is fairly PostgreSQL compatible and works well
with pg-el. Last tested
@@ -195,7 +198,7 @@ The following PostgreSQL-compatible databases or extensions
have been tested:
`pg_catalog.pg_types` table are not the same as those used by PostgreSQL
(e.g. `Int64` instead of
`int8`), so our parsing machinery does not work. This database also has more
restrictions on the
use of identifiers than PostgreSQL (for example, `id` is not accepted as a
column name, nor are
- identifiers containing Unicode characters). Last tested v0.15.2 in 2025-07.
+ identifiers containing Unicode characters). Last tested v0.16 in 2025-08.
- Hosted PostgreSQL services that have been tested: as of 2025-06 render.com
is running a Debian
build of PostgreSQL 16.8 and works fine (requires TLS connection), as of
2024-12
@@ -217,7 +220,7 @@ PostgreSQL variants that **don't work** with pg-el:
- The [ReadySet cache](https://github.com/readysettech/readyset) does not work
in a satisfactory
manner: it generate spurious errors such as `invalid binary data value` when
using the extended
- query protocol (last tested 2025-07).
+ query protocol and is unable to parse certain timestamps (last tested
2025-08).
Tested **Emacs versions**: mostly tested with versions 31 pre-release, 30.1
and 29.4. Emacs versions
