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!
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...