Smokes your problems, coughs fresh air.
My profile on PGXN—The PostgreSQL Extension Network—has a list of all my publically released PostgreSQL extensions. Or search my GitHub profile for my PostgreSQL stuff mirrored there.
Since my initial announcement here of pg_safer_settings, my extensions for safe (through per-column GRANTs), fast (through IMMUTABLE, auto-(re)generated accessor functions) settings has matured quite a bit, and is now at version 0.8.12.
Soon, later this month, still in the first quarter of 2024, I expect to release the first officially stable 1.0 version…
I just released pg_text_semver version 1.0.0 on PGXN. As usual, it’s also available for your forking pleasure.
Upgrading from 0.1.5 to 1.0.0 should be seamless. As usual, upgrade scripts are provided, though I didn’t need to according to the Semantic Versioning for pre-1.0 releases. 😉
Since my initial release, I’ve learned that, besides the pre-existing semver extension that I tried before developing pg_text_semver, there also existed a PG_SEMVER extension that I did not test and compare with my own solution. It might certainly be faster than my version, given that both these other extensions have their crucial parts written in C. (Performance was really not an issue for my use case – much less so in any case than completeness, correctness and ease of use.) See the Alternative to pg_text_semver section of the README for more details.
Early during the development of the PostgreSQL backend for FlashMQ.com—that is our amazing managed MQTT hosting service!—, I decided on using UUIDs rather than auto-incrementing integers wherever I needed or wanted surrogate keys. I am one of those people who prefers the use of natural keys where their use is … natural, but I certainly have nothing _against_ surrogate keys, only to their overuse, which usually results from an over-reliance on ORMs (which I do have something against). There are a couple of advantages to using UUIDs over auto-incrementing integers (available in PostgreSQL via sequences):
I needed to compare semantic versions within Postgres. I tried the existing semver extension, but when I found that it was a bit problematic to adjust to be fully compliant with the semantic versioning spec, I decided to write a simple domain-based alternative myself: pg_text_semver.
(Version parsing was part of my effort for more robust pg_restore of FlashMQ extension data. I might write more about that in the future.)
My newest PostgreSQL extension—pg_extra_time—contains the date-time functions, operators and casts that I was surprised to not find in the standard library. Maybe one day…
Again, this extension is a shoot-off from the PostgreSQL work I’m doing for the backend of the high-performant FlashMQ.com MQTT hosting service, that is due to launch later this quarter.
Like most of the FlashMQ.com PostgreSQL extensions, pg_extra_time is also available via PGXN—The PostgreSQL Extension Network: https://github.com/bigsmoke/pg_extra_time
Yesterday, I released a tiny PostgreSQL extension that I use to validate email address in the backend of FlashMQ.com: pg_html5_email_address validates email addresses in the same way that modern web browsers do for <input type="email"> elements.
The advantage of having email validation in your data backend to be in sync with the HTML5 spec is twofold:
pg_html5_email_address is available on PGXN: https://pgxn.org/dist/pg_html5_email_address/1.1.0/
And now there is pg_xenophile too, the seventh spin-off extension of the robust, efficient PostgreSQL backend for our scalable MQTT hosting platform: FlashMQ.
pg_xenophile is also available via PGXN: https://pgxn.org/dist/pg_xenophile/
Yet another PostgreSQL extension that emerged from the FlashMQ PostgreSQL backend is: pg_safer_settings. pg_safer_settings offers some functions and a mechanisms to make working with settings in PostgreSQL a bit safer. Its defining features are:
My latest split-off release from our super-stable FlashMQ.com PostgreSQL backend is version 1.0.0 the pg_utility_trigger_functions. It’s a very simple bundle of a bunch of trigger functions that I find useful to carry around with me, and it’s sufficiently-tested for me to bring it out immediately under a 1.0.0 stamp.
Another release from the long list of PostgreSQL extensions that I’m splitting off from the database schemas that make up our rock-solid MQTT hosting platform issss: pg_role_fkey_trigger_functions. That extension name is quite the mouthful. From its readme (again courtesy of pg_readme):
The pg_role_fkey_trigger_functions PostgreSQL extension offers a bunch of trigger functions to help establish and/or maintain referential integrity for columns that reference PostgreSQL ROLE NAMEs.
Many extensions are yet to come, because I’ve found that dependencies in themselves aren’t bad, as long as they are used side by side, and not needlessly stacked on top of each other. That they are no longer 100% internal to the migrations belonging to the app doesn’t worry my, because:
© 2025 BigSmoke
Theme by Anders Noren — Up ↑
Recent Comments