xtdb 2024-07-22

Hey all - new XT2 snapshot release incoming 🚀 This one's got a couple of breaking changes: â€Ē The 'xtdb-s3' module has been renamed to 'xtdb-aws' - we'll include support for other AWS modules in here. First (the one that led to the change): CloudWatch metrics 🙂 â€Ē The pgwire module has been removed ... because its functionality has moved to 'xtdb-core', as the primary means of talking SQL with XT2 🐘 Notable additions: â€Ē Timestamp types now supported in pgwire â€Ē plan-q added to xtdb.api, à la next.jdbc â€Ē Ability to control the size of the local disk cache â€Ē Otherwise, mostly performance work 🏃 Have a look at the https://github.com/xtdb/xtdb/milestone/44?closed=1 for the full list. Cheers!

âĪïļ 4

Have you tested https://github.com/igrishaev/pg2 with XTDB via pgwire?

we've not; we should 🙂

I should say it's still relatively early days for the pgwire driver as yet - we get the simple stuff right but whenever you get a tool to connect using a Postgres connection string it then makes a lot of assumptions about the amount of Postgres-specific SQL/metadata available. We're chewing through these but it's mostly a game of trying each individual tool and seeing what queries it runs 😅 If anyone's got any favourite tools, give us a shout and we can try to prioritise those ones

Since you don't have a JDBC driver, the choices from Clojure as far as SQL is concerned are: â€Ē next.jdbc.xt -- faking the API to somewhat pretend it's like JDBC (which I don't think is a good solution long term -- lots of pieces in next.jdbc don't work properly this way) â€Ē pg2 -- as above â€Ē xtdb.api -- which is kind of its own weird interface The first two sort of make XTDB look like "any other database" to some extent; the latter accepts that it's a unique thing with its own custom integration code

(writing and using next.jdbc.xt made me realize just how thin a wrapper next.jdbc is around JDBC 🙂 and how many assumptions about JDBC it makes)

you should be able to use next.jdbc using the Postgres JDBC driver and a Postgres connection string?

Oh, and rely on the PG driver to do the underlying pgwire comms? Hmm, I haven't tried that, but I think that will depend on quite a bit of JDBC metadata to work, since even calling .getTableName() -- which is how next.jdbc creates qualified keywords in results -- causes additional queries to run, to fetch/decode JDBC metadata...

The PG JDBC driver expects to connect to port 5432 by default and I hadn't thought about whether that's a pgwire endpoint 🙂

seems ok in practice - quite a lot of our pgwire tests run through next.jdbc 🙂

Ah, good to know... Then I think I will deprecate next.jdbc.xt then...

ðŸŠĶ 1
ðŸŦĄ 1