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