Learning about "transqlate" at PG Session 16

After the craziness of the FOSDEM weekend in Brussels (FOSDEM PGDay, and the PostgreSQL booth and Devroom at FOSDEM itself) I headed to Paris for PG Session 16 on Wednesday 7 Feb. It was great to spend the day with some of the French-speaking PostgreSQL community. A huge thank you and congratulations to the organisers!

There were some great talks, including Arnaud de Vathaire et Pierrick Chovelon describing some of the new features of PostgreSQL 16, and Bertrand Drouvot explaining logical decoding from a standby server (introduced in version 16). Lætitia Avrot used a Star Wars theme to inject some fun into learning about indexes (and as an excuse to introduce Marcus Winand's excellent Use the Index, Luke), and I gave a talk called Quel est le contraire d'un hot-dog (Trouvons la réponse avec Postgres et l’IA), or "What's the opposite of a hot-dog (using Postgres and AI to find out)". The talk is based (with permission, of course) on Chris Winslett's blog What's Postgres Got To Do With AI? and gives an introduction to using the pgvector Postgres extension to store and query embeddings to look at the "relatedness" of two recipes. Pierre Bonhomme gave an interesting talk about how his team migrated a live cluster from repmgr to Patroni without downtime, and Frédéric Yhuel gave some pointers on how to work with execution plans.

One of the highlights of the day for me was learning about and seeing a demo of the transqlate tool that's in early development at Dalibo Labs. Thank you to DBA Florent Jardin and developer Étienne Bersac for presenting it to us. transqlate is a transpiler with a simple CLI (simple to use, that is - it obviously hides plenty of complexity under the hood) that converts code snippets from one SQL dialect to another. The creators are open to enhancing the tool to convert between any two dialects, but the current version implements Oracle as the source and PostgreSQL as the target. Funnily enough, they say they haven't yet had a request to implement any other target dialect! This could be a really handy tool to help with migration projects, or even just to help existing Oracle or other DBAs or developers to write code that will work on Postgres databases. I'm looking forward to digging into the repo, and giving the tool a try, to understand more about how it works and what's been implemented so far. It will also be interesting to look at how it complements and/or overlaps with existing migration tools such as Ora2PG (which focuses on migrating the schema and data from Oracle to Postgres, rather than database code).