branch: elpa/pg
commit e7fe328e23453c84b3eaf93cfc32d7b5d5570aff
Author: Eric Marsden <[email protected]>
Commit: Eric Marsden <[email protected]>
Update the information on tested variant versions
---
README.md | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/README.md b/README.md
index ba995dc5f86..74aa814a4cd 100644
--- a/README.md
+++ b/README.md
@@ -42,7 +42,7 @@ This library has support for:
- Connections over TCP or (on Unix machines) a local Unix socket.
-Tested **PostgreSQL versions**: The code has been tested with versions 18.0,
17.6, 16.5, 15.4,
+Tested **PostgreSQL versions**: The code has been tested with versions 18.1,
17.6, 16.5, 15.4,
13.8, 11.17, and 10.22 on Linux. It is also tested via GitHub actions on MacOS
and Windows. This
library also works, more or less, against other “PostgreSQL-compatible”
databases. There are four
main points where this compatibility may be problematic:
@@ -105,9 +105,6 @@ The following PostgreSQL-compatible databases or extensions
have been tested:
statements and prepared statments named `__pgdog_N` are reported not to
exist. The pooler also
disconnects the client when the client-encoding is switched to `LATIN1`
(last tested 2025-08).
-- The [PgCat](https://github.com/postgresml/pgcat) sharding connection pooler
for PostgreSQL (MIT
- license). Mostly works but sometimes runs into read timeouts (last tested
2025-08 with v0.2.5).
-
- [Google AlloyDB Omni](https://cloud.google.com/alloydb/omni/docs/quickstart)
is a proprietary fork
of PostgreSQL with Google-developed extensions, including a columnar storage
extension, adaptive
autovacuum, and an index advisor. It works perfectly with pg-el as of
2025-08 (version that
@@ -130,11 +127,11 @@ The following PostgreSQL-compatible databases or
extensions have been tested:
though the `pg_sequences` table is not implemented so certain tests fail.
YugabyteDB does not have
full compatibility with PostgreSQL SQL, and for example `GENERATED ALWAYS
AS` columns are not
supported, and `LISTEN` and `NOTIFY` are not supported. It does support
certain extensions such as
- pgvector, however. Last tested on 2025-09 against version 2.25.
+ pgvector, however. Last tested on 2025-11 against version 2.25.
- The [RisingWave](https://github.com/risingwavelabs/risingwave) event
streaming database (Apache
license) is mostly working. It does not support `GENERATED ALWAYS AS
IDENTITY` or `SERIAL`
- columns, nor `VACUUM ANALYZE`. Last tested 2025-10 with v2.6.0.
+ columns, nor `VACUUM ANALYZE`. Last tested 2025-11 with v2.6.2.
- The [CrateDB](https://crate.io/) distributed database (Apache licence).
CrateDB does not support
rows (e.g. `SELECT (1,2)`), does not support the `time`, `varbit`, `bytea`,
`jsonb` and `hstore`
@@ -142,14 +139,14 @@ The following PostgreSQL-compatible databases or
extensions have been tested:
PostgreSQL functions such as `factorial`, does not return a correct type OID
for text columns in
rows returned from a prepared statement, doesn't support Unicode
identifiers, doesn't support the
`COPY` protocol, doesn't support `TRUNCATE TABLE`. It works with these
limitations with pg-el
- (last tested 2025-10 with version 6.0.2).
+ (last tested 2025-11 with version 6.0.3).
- The [CockroachDB](https://github.com/cockroachdb/cockroach) distributed
database (source-available
but non-free software licence). Note that this database does not implement
the large object
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-10 with CockroachDB CCL v25.3).
+ tested 2025-11 with CockroachDB CCL v25.4).
- 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
@@ -159,21 +156,21 @@ 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-10 with Materialize v0.159).
+ limitations with pg-el (last tested 2025-11 with Materialize v0.164.1).
- 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
- 2025-10 with CedarDB version v2025-10-07.
+ 2025-11 with CedarDB version v2025-11-06.
- The [QuestDB](https://questdb.io/) time series database (Apache licensed)
has very limited
- PostgreSQL support, and does not support the `integer` type for example.
Last tested 2025-09 with
- version 9.0.3.
+ PostgreSQL support, and does not support the `integer` type for example.
Last tested 2025-10 with
+ version 9.2.0.
- The proprietary [Yellowbrick](https://yellowbrick.com/) distributed database
does not implement
`SERIAL` columns, nor datatypes such as `text`, `bit` and `timetz`, nor
collation, nor enums, nor
functions such as `gen_random_uuid`, nor large objects. It has limited
support for the UTF8
encoding, and its implementation of the `numeric` type is buggy. It works
with these limitations
- with pg-el (last tested 2025-08 with version 7.4.0 of the YellowBrick
community edition).
+ with pg-el (last tested 2025-11 with version 7.4.0 of the YellowBrick
community edition).
- [Google Spanner](https://cloud.google.com/spanner) proprietary distributed
database: tested with
the Spanner emulator (that reports itself as `PostgreSQL 14.1`) and the
PGAdapter library that
@@ -194,14 +191,14 @@ The following PostgreSQL-compatible databases or
extensions have been tested:
are many limitations in the PostgreSQL compatibility: no user
metainformation, no cursors, no
server-side prepared statements, no support for various types including
arrays, JSON, UUID,
vectors, tsvector, numeric ranges, geometric types. It works with these
limitations with pg-el
- (last tested 2025-07 with YottaDB 2.0.2).
+ (last tested 2025-11 with YottaDB 2.0.2).
- The [GreptimeDB](https://github.com/GrepTimeTeam/greptimedb) time series
database (Apache license)
implements quite a lot of the PostgreSQL wire protocol, but the names it
uses for types in the
`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.17 in 2025-09.
+ identifiers containing Unicode characters). Last tested v1.0.0-beta1 in
2025-11.
- 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
@@ -209,15 +206,17 @@ The following PostgreSQL-compatible databases or
extensions have been tested:
[Aiven.io](https://aiven.io/) is running a Red Hat build of PostgreSQL 16.4
on Linux/Aarch64 and
works fine. [TheNile](https://thenile.dev/) is running a modified version of
PostgreSQL 15, and
has several limitations (for example, comments on tables and comments don't
work, you can't create
- functions or procedures).
+ functions or procedures). As of 2025-10, the free tier of the Timescale
instance hosted by Tiger
+ Data works fine. As of 2025-11, the free tier of Supabase works fine (you
will probably have to
+ increase the read timeout using the `read_timeout` URL parameter).
- Untested but likely to work: Amazon RDS, Google Cloud SQL, Azure Database
for PostgreSQL, Amazon
Aurora, CrunchyData Warehouse. You may however encounter difficulties with
TLS connections, as
noted above. Reports on success or problems encountered with these databases
are welcome.
-PostgreSQL variants that **don't work** with pg-el:
+PostgreSQL variants or proxies that **don't work** with pg-el:
-- The ClickHouse database, whose PostgreSQL support is too limited. As of
version 25.8 in 2025-09,
+- The ClickHouse database, whose PostgreSQL support is too limited. As of
version 25.10 in 2025-11,
there is no implementation of the `pg_types` system table, no support for
basic PostgreSQL-flavoured
SQL commands such as `SET`, no support for the extended query mechanism.
@@ -225,8 +224,12 @@ PostgreSQL variants that **don't work** with pg-el:
manner: it generate spurious errors such as `invalid binary data value` when
using the extended
query protocol and is unable to parse certain timestamps (last tested
2025-08).
+- The [PgCat](https://github.com/postgresml/pgcat) sharding connection pooler
for PostgreSQL (MIT
+ license) does not work correctly with prepared statements (last tested
2025-11 with v0.2.5).
+
+
-Tested **Emacs versions**: mostly tested with versions 31 pre-release, 30.1
and 29.4. Emacs versions
+Tested **Emacs versions**: mostly tested with versions 31 pre-release, 30.2
and 29.4. Emacs versions
older than 26.1 will not work against a recent PostgreSQL version (whose
default configuration
requires SCRAM-SHA-256 authentication), because they don’t include the GnuTLS
support which we use
to calculate HMACs. They may however work against a database set up to allow
unauthenticated local
