| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: ISBN range table |
| Date: | 2026-04-14 03:04:32 |
| Message-ID: | CA+hUKGKkt5AcwmkAskvpx7YtXOTq0ntxA3wVa=3YFQNqMkaDVw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Apr 12, 2026 at 11:37 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> A recent-ish thread[1] made me wonder what that big table of data
> does, and why we have a random update every decade or so, and I came
> up with the attached.
Fixed a couple of typos and added as commitfest #6676. The idea is
that update_isbn.py would become another periodic update task, similar
to Unicode, contrib/unaccent and the IANA timezone stuff. I suppose
running it only for major releases would be enough for such
non-critical data. There are also some other much smaller tables in
this contrib module, but they don't seem to be moving (?) so I didn't
look at them.
I'm not volunteering today, but a passing thought I had while browsing
this complicated code full of scary pointer arithmetic is that it
might be an idea to try to describe the entire EAN3 number space in a
much simpler single binary-searchable array that maps uint64_t ranges
to TO_CHAR format strings, with entries that look something like:
{9780037000000, 9780638999999, "999-9-99-999999-9"}
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-contrib-isb-Update-ISBN.h-automatically.patch | text/x-patch | 60.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-04-14 03:13:40 | Re: tablecmds: fix bug where index rebuild loses replica identity on partitions |
| Previous Message | Chao Li | 2026-04-14 02:49:38 | Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value) |