extendable psql?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: extendable psql?
Date: 2026-08-28 19:27:44
Message-ID: CAFj8pRDHBpnAhynXHoNkEU=4SsPYm1Pz+C+vzwW2gkf8qUfztQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Last month I played with the possibility of integrating the Lua language to
psql. You can test this feature - patch is attached. Execute configure with
--with-lua option.

I don't propose the integration of Lua to psql - although it was relatively
simple. The Lua language is probably on all platforms and has friendly
licence, but I'm afraid never ending discussions "why Lua, why not Python
or any other popular language. I tested usability, and I think it can work
well. With minimal effort I wrote two features (for psql), that were
discussed last years - an alternative of \dt command with possibility to
sort by size, and a wrapper for VACUUM with more readable verbose output
and with progress information. I think there is a space for some features
like this - and writing tools like https://github.com/NikolayS/postgres_dba
can be much easier with a complete programming language.

So the question is not - how to integrate Lua to psql, but how to allow
extending psql if we want to extend psql.

One of my ideas was forking psql - but cutting psql from upstream can be
ugly work, so I don't think it is the way.

What do you think about the possibility of extending psql?

Note: I started with Lua a few weeks ago, so a lot of things can be done
better and more effectively. This is PoC, but it's workable.

Regards

Pavel

Usage:

\luafile ~/vacuum.lua
\luafile ~/mydt.lua

\my.dt+ public.* -desc-size
\lua vacuum {verbose=true}

Attachment Content-Type Size
vacuum.lua text/x-lua 2.3 KB
mydt.lua text/x-lua 2.7 KB
0001-This-patch-for-PostgreSQL-master-branch-contains-an-.patch text/x-patch 98.5 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-08-28 19:43:22 Re: Allow table AMs to define their own reloptions
Previous Message Antonin Houska 2026-08-28 19:15:25 Re: REPACK (ANALYZE) within transaction block segfaults