The version of postgres you think you're specifying isn't exactly the community postgres, it's an AWS maintained fork and this is an example of where they were seeing an error message from a future version of postgres that had been back-ported in the fork (or maybe AWS contributed to PG and it landed in a later version).
---
I guess I knew this - it's obviously not the exact same version, when you stop to think about it (pretty sure the doco tells you this explicitly too).
But I've never personally observed a difference, so I never really gave it a thought.
Seems like it might have more legs than the usual "postgres should get query hints" requests that the PG team generally don't entertain.
> "I think we've become so negative about hints that we rarely have a rational discussion about them... I also don't enjoy telling a customer 'hey, I know this query started misbehaving in the middle of the night on Christmas, but hints are bad... you can just have your web site be down for the next 20 years while we try to improve the optimizer.'"
Above quote is from the author of pg_plan_advice itself, from a few years ago.
So given his proposal isn't just band-aiding query hints into PG, is from a committer instead of being a drive-by patch, and might be even more generally useful/applicable than "add query hints" - maybe we could see some movement here.
If you're building a brand new, multi-language, multi-platform system that uses advanced open-api features - you will get bitten by lack of support in 3.1 versions of tooling for features that already existed and work fine right now in 3.0 tool versions. Especially if you're using a schema-first workflow (which you should be). For example, $ref's to files across windows/linux/macos across multiple different language tools - java, .net, typescript, etc.
If you need (or just want) maximum compatibility across tools, platforms and languages - open-api 3.1 is still not viable, and isn't looking like it will be anytime soon.
That's some serious forward thinking you've got going on with your date format there. I like it, I will be formatting all my years to 5 digits from now on.
OTOH, if it was just a typo - keep it to yourself, I don't wanna know. I'm all in - 5 digit years is a thing now.
This, with TypeScript strictness cranked all the way up.
MUI for the component library, plus Playwright for integration-testing and hoverfly to stub/fake/mock the backend, and Open-API to define the APIs between app -> bff -> backend.
This stack, plus claude-code, with the whole project fully automated (i.e. claude-code run all the parts easily) - is a literal productivity super-power. You can crank out entire complicated LoB apps, 10 - 30 pages of distinct, medium-complicated functionality in about a week, if not less - instead of weeks or months. Fully tested, production-ready codebase, not prototype-tier/vibe-code.
Unsurprisingly, minimising the amount of cognitive complexity is how you get the most out of LLM coding agents. So now have a theoretically repeatable way to measure cognitive load as contextualised to software engineering.
I've built https://kopi.cloud to try to provide an alternative option in between being locked in to a big mail service and running your own mail servers.
It's a consumer-oriented SaaS for taking control of your personal mail - there is no enterprise pricing, nor even a subscription pricing option - though you can you can choose to pre-pay for the service years in advance.
Kopi uses Amazon SES for email delivery. We know Amazon wants to make sure that their service is a viable product for mail delivery at the commercial enterprise level. The idea is that Kopi can survive as a viable retail product by riding on the coat-tails of that desire and arbitraging the cost of mail handling via SES so it's cost-effective at consumer level.
The intention is to run it as cheaply as I can, ($1USD / month at the moment, though I make no guarantee that it can stay that cheap forever) and to give people the ability to choose between different mail services.
The idea is that you can manage your own domain, and setup your DNS to use Kopi as your mail exchange via DNS MX records to forward your email to whatever mail service you choose to use.
If people don't want to even run their own domain, they can can use the shared Kopi domains if they want - with the understanding that those mail addresses are locked to the Kopi service, but at least they can change mail service whenever they want.
The goal is to be easy enough to use that you can set up your email handling via a smart phone, and cheap enough that running your own email handling using free software should seem expensive by comparison.
Though I'll admit - marketing this thing is a bit of a problem right now :)
My current SaaS project is https://kopi.cloud, it lets you keep your email address private via email forwarding / mail-to-rss functionality.