Introducing pgLantern, a Postgres Archive API

19 Jul, 2026

I've been looking for a way to start exploring the PostgreSQL source code. The code is extremely well linked, with every commit linking to a message or a thread, and the message archives linking to patches. However, none of those links can be scripted or queried, and the archives are huge.

So I'm introducing pgLantern, which is my solution in the form of a free API connected to a pipeline that stitches together all the commits and messages across the entire PostgreSQL community and then, crucially, exposes everything as JSON.

It comes bundled with a CLI, which you'll see shortly. Now, instead of diving into its features, I want to take you on a trip through an extremely stable, but also quite small, portion of the source code to see what it can do.

Last year I briefly introduced pg-trgm to anyone who missed it, either because they work in MySQL or because they, like me, spent the first years of their career keeping their SQL "portable" (Portability is overrated, use your tools to their fullest extent).

Now, pg-trgm is pretty stable. It was first added to Postgres in 2004 by Teodor Sigaev.

> lantern commits --path contrib/pg_trgm --sort committed --dir asc --limit 1

SHA       AUTHOR        COMMITTED   SUBJECT
cbfa4092  Teodor Sigaev 2004-05-31  trgm - Trigram matching for Postgres

Since then, it's seen 324 commits, with the most recent one...nine days ago?

> lantern commits --path contrib/pg_trgm --limit 1 --json | jq '.data[0].committed_at, .total'

"2026-07-11T12:39:15Z"
324

The recent topics of discussion seem to be on how meson interacts with llvm bitcode and a fix for loop variables.

> lantern activity contrib/pg_trgm

KIND     AT          SUBJECT                            REF
message  2026-07-17  Re: meson vs. llvm bitcode files   CAN55FZ...
message  2026-07-17  [PATCH] Rename "getdatabaseen"...  CAB8KJ=...
commit   2026-07-11  Fix for loop variables             e615da8...
message  2026-07-06  Re: meson vs. llvm bitcode files   CAN55FZ...
message  2026-07-01  Re: meson vs. llvm bitcode files   CAN55FZ...
message  2026-06-24  Re: Interrupts vs signals          0aac2b1...
message  2026-06-23  for loop variable fixes            d639aed...

The fix for loop variables seems like a good place to start, since loops are something you don't need any C to understand. It looks like this commit touched a small number of lines across a lot of files, which matches the message.

> lantern commits get e615da8cb21b3745
Commit:        e615da8cb21b3745456da45197fa5dc620f19dab
Author:        Peter Eisentraut
Authored at:   2026-07-11T12:38:33Z
Committer:     Peter Eisentraut
Committed at:  2026-07-11T12:39:15Z
Release:       master
Archive:       https://postgr.es/c/e615da8cb21b3745456da45197fa5dc620f19dab
Link:          https://pglantern.com/commits/e615da8cb21b3745456da45197fa5dc620f19dab

Fix for loop variables

A number of for loops used loop variables that did not match the type
of the end condition.  This could lead to wraparound or
signed/unsigned mismatches.  Probably none of these are a problem in
practice, but it's fragile code.

Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/d639aede-209f-412b-927a-d38d4848b370%40eisentraut.org

PATH                                                          CHANGE  ADD  DEL
contrib/pageinspect/fsmfuncs.c                                M       +2   -3
contrib/pageinspect/hashfuncs.c                               M       +2   -3
...

Yep, this is a general loop improvement. More specific types on the loop iterators, making sure they match the type of the final loop-terminating condition. This is the kind of optimization and polish you get with hundreds of eyes on the code.

        trgm       *ptr = GETARR(add);
        int32       tmp = 0;
 
-       for (i = 0; i < ARRNELEM(add); i++)
+       for (unsigned i = 0; i < ARRNELEM(add); i++)
        {
            CPTRGM(&tmp, ptr + i);
            HASH(sbase, tmp, siglen);

But what about that meson vs llvm topic? It started in 2024 when Peter Eisentraut (who we just saw fixing the loops!) mentioned:

The meson build currently does not produce llvm bitcode (.bc) files. AFAIK, this is the last major regression for using meson for production builds.

Is anyone working on that? I vaguely recall that some in-progress code was shared a couple of years ago, but I haven't seen anything since. It would be great if we could collect any existing code and notes to maybe get this moving again.

I'm not very familiar with the C ecosystem, but I am familiar with trying to switch to a new build system and trying to get the last few bits of compatibility sorted out to finally cut over in production.

> lantern messages thread 'CAN55FZ26ohM...' --json --full | jq '.data[0].sender.display_name, .data[0].sent_at, .data[0].body_text'

Peter Eisentraut
2024-09-05T08:56:26Z
The meson build currently does not produce llvm bitcode (.bc) files...

Notably, it does seem that the extension is acting as a smaller test-bed for the new build system configuration. Which makes sense, it's only a few files and is extremely stable.

What can we conclude from all this? Pretty much what we'd expect, that the 22 year old extension in PostgreSQL is stable and mostly changes as one component of a larger refactor.

Still, it's an interesting test case for pgLantern, which can link and query all of this. Some other features I left out:

The ability to subscribe to be notified when commits to a path are added, a thread is updated, or a specific sender is active. Notification is currently via email, but webhooks are coming soon as well.
lantern generate-skill <destination path> will generate a SKILL.md file to teach your coding agents.
An MCP server is in the works to complete the "deterministic API making it's data available to LLMs" feature set.

I hope you enjoy using it.

#postgresql