> Sooo.... "be more professional in your writing"?
No, just more precise. It seems absurd to brand an entire community as "assholes" based on some disagreement with a blog post by one member. I suspect great GP didn't mean it that way, but it would help to have some clarification.
To be precise, they said “the kind of contributors you attract with this kind of writing are just assholes” not “the community is only assholes” and also not “anyone who associates with him is an asshole". You’re strawmanning.
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.
The solution here is to demand support for the most recent specification version from your tooling vendors. We (the OpenAPI TSC) sometimes hear from vendors "we're not moving quickly to support the latest version because our users aren't asking for it." So it's a catch-22 unless you make your needs known.
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.
> I like it, I will be formatting all my years to 5 digits from now on.
Please don't, it's highly irritating and usually just serves as a way to get people to discuss the leading zero rather than the subject they were really interested in in the first place. Leading zeros aren't a thing for a reason. It's about as useful as expressing the temperature in Kelvin.
Degrees Kelvin has its place, just as leading zeros. The Farmer's Almanac may have a point but if they do I can't see it and to put a leading zero in front of a year is just annoying. Think about it: how would you pronounce the dates from now on, are you really going to say 'Today is the 7th of november of zero-two-zero-two-five'? And why stop at one zero, really forward thinking people should start counting from the big bang up, that's as close as you can get to the Kelvin analogy, might as well take it all the way then.
Well said. Five-digit years are the Shadow the Hedgehog of rationalism. But he successfully derailed the thread and took the spotlight for himself, so... mission accomplished, I guess.
That was a synthesized example of how they insert years seemingly for the sake of formatting it weirdly. Now that I’ve pointed it out to you, next time you see this come up, ask yourself if anyone else would have mentioned a date in that context.
If I were them, I might end this comment with “I haven’t seen it done like that since I first got online, in around 01993.”
How many of those are actually (New England) zip codes? (and of the ones that are years, how many of them are "kragen is at it again" :-) Seriously, I've never noticed a thread on these and not found a kragen post as a trigger, but there's probably sampling bias in that - or maybe the intersection of "people who are into the Long Now Foundation" and HN posters is that small?)
If they aren't a thing, why are we talking about them? Clearly they're a thing. And not even an obscure thing. If you've ever used commonly used representations like ZIP codes, bank account numbers, or serial numbers you'll no doubt have encountered it before. And that even goes for dates. ISO 8601, for example, requires leading zeros, including for the year component. "1" is not considered a valid year under that standard. It must be represented as "0001". Granted, ISO 8601 only requires a minimum of four characters to represent the year, but expecting at least five characters is conceptually just as valid.
The question asks why we're talking about something that is purportedly not a thing, not a quest to find further confirmation of it being a thing. Swing and a miss.
RFC 2550 Section 3.1 has years from 0000 to 9999 as four digit but zero padded (so the fall of Rome was 0476). It then gets appropriately weird as it was published April 1, 1999.
this thing where someone performs an in group practice (the leading zero behavior) to garner interest, and then another in group member appears to try to recruit the curious person who takes the bait, that y'all are doing?
it's creepy cult behavior, and the "Long Now" name and framing focused on the infinite isn't helping
> 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.
I like this.
I wonder what other conventions we could break by being "forward-thinking" in this sense.
Past tense for all proper names ("America was...", "Google was..."), prices pegged to energy equivalents (bananas were priced at 10 kWh). Describing life on the North American Plate under Alpha Centauri aligned constellations...
Those are all awkward. The date thing is just smooth.
