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.
"micro-management" is not a useful concept, it's just a though-terminating cliche - let's get specific.
The problem with bad stand-ups is usually that they're just "personal status updates" by another name. They're abused as a way for team lead/project manager to "get a feel" for what individuals on the team are doing. Bad managers do this, because they're bad at their jobs. It's literally their job to know what people are doing, where they're at in their various tasks, what's going on with the project. They should be doing that all day, every day - when they're not "managing up". Gathering info in a 15 minute standup is both too short a feedback cycle and too long and nowhere near high enough bandwidth. It's also one of the major reasons stand-ups frequently go off the rails and end up taking so long, in badly run projects. Stopping those derailments is actually supposed to be one of their jobs and should be one of their main priorities during the stand up.
If you're stand-up involves going around the team, one person at a time asking "what did you do yesterday, what are you doing today" - that's a bad stand-up.
Stand-ups should be run from the sprint board - you run through all open tickets for the sprint, asking whoever is assigned to that ticket "what's up with that?"
Once you've gong the through the tickets, you're done. No looking forward to next sprint - that's for backlog grooming and planning sessions. No looking backward, that's for retros.
Don't get to talk during the stand-up? Then WTF are you even working on, and why isn't a story in the sprint? That's a question the manager should be asking and resolving - privately, outside of the standup.
Stand-ups are for "visibility of the team, for the team". Not for managers or other wanna be management.
Stand-ups are for telling your teammates "i unstuck this ticket this way, if that's an issue or there's a better way, hit me up after the standup" or "I'm going to be working on X and I don't know anything about that; anyone who can help me, hit me up after the standup".
If your stand-ups aren't like that they're bad stand-ups. Because your manager sucks. Don't worry - most managers suck. Deal with it, get over it; and stop blaming your tools.
But a naive increase will punish the majority of customers who aren't yet using a similar efficiency mechanism.
My guess, if this approach becomes popular - we'll see a whole new layer of complexity added to Lambda pricing making it even harder to estimate lambda costs ahead of time.
So this tech has been out there for a while now and Vercel users are starting to see the benefits.
If this IS working out well, it won't be long before non-Vercel solutions start popping up.
AWS have already calculated the pricing model of lambda to take advantage of this massive inefficiency of their lambda product, they charge multiple customers simulatnaeously to use for the same hardware for the compute that would otherwise be sitting idle 95% of the time due to Lambda's basic design.
If large numbers of customers start using this model to reduce AWS' ability to double-dip, it's going to severely affect the profitability of Lambda, I wonder how AWS will respond?
Plus, they're getting real world training data from everyone who either hasn't or doesn't have the ability to opt out of their stuff being used.
For my personal stuff, I don't opt out of training for this very reason. What's more, I resent Stack Overflow and Reddit etc. trying to gate-keep the content that I wanted to give to the community and charge rent for it.
I used to intentionally post question-answer style posts where I would both ask the question,wait for a while, then answer the question on both Reddit and Stack Overflow. I don't do that anymore because I'm not giving them free money if they're not passing some of the benefit on to the community
Yesterday, I was thinking "is it just me or did this get way dumber than it was yesterday?"
Turns out: nope, Claude Sonnet regressed and got significantly dumber. The internet, obviously, assumed dastardly intent from Antrhopic. But they reckon "nope, we messed up - sorry about that, but hey - stuff happens".
It's kind of scary how Anthropic makes a change that makes the model dumber and my knee-jerk reaction is "What am I doing wrong? Am I getting dumber?".
And their response doesn't exactly inspire confidence either.
My current SaaS project is https://kopi.cloud, it lets you keep your email address private via email forwarding / mail-to-rss functionality.