Did I mention that it would be really nice to have #PostgreSQL as an embeddable library similar to #SQLite? Size wise that should be fine, I think the whole PG daemon is just ~5MB.
I know that the architecture doesn't lean to it, but someone has to do this eventually! 🙂
@ascherbaum It seems clear that you haven't used SQLite at all 🙂 PG w/o the server parts (which have zarro relevance for embedded) is nothing like SQLite. PG is way, WAY more advanced and powerful. It would be a blessing to have that available as a lib, and it would be nothing like SQLite.
(which would still be good for apps that require the absolute minimum of resource consumption, but PG is so efficient too, it will rarely matter)
@ascherbaum In what contexts did you use SQLite? (and how and why) (asking because I literally can't imagine a single reason why I would use libsqlite3 over libpg if that would exist).
@ascherbaum Of course I look at that from the "what I want" perspective, that's how progress happens! I don't want to be stuck w/ SQLite, I want the proper PG functionality applicable for the in-app use case.
For a reason, I acknowledged from the start that PG has large architectural issues being such an old software codebase, to restate: "I know that the architecture doesn't lean to it".
That doesn't imply it shouldn't happen, because the want exists. And I hope we'll see it eventually 🙂
@ascherbaum Your original claim that libpg would be: "But then you have... SQLite again" is just non-sense given the disparity in functionality.
But at least you managed to retour to the actual issue that the PG codebase is not well equipped for this. 👍 You may not care, but I hope someone gets this going, it would be quite awesome.
@ascherbaum I didn't actually raise any question, so there is nothing to turn around. But given that you have used SQLite "extensively", what do you think, could it gain the PG functionality, build on what's there today? 🙄
@ascherbaum Excellent, this is precisely what I'm talking about. No, it will never. If you listened to that presentation and ever used SQLite you'd know that it is in no way fit for the task. Heck, it doesn't even have proper typing.
Yes, I do think of PostgreSQL as a programming language (kinda the whole point).
And yes, PG is the best available reference platform available (also the point)
This is why we "need" it as a lib for embedding (we can still use SQLite instead of CSV's).
@ascherbaum WWPD, I'm not sure, I think it is fine if PG itself stays the fine tuned, ages old, monolithic code base, just for servers. That's what it was originally setup for.
The thing I'm asking for is an embedded variant. Probably a fork similar to TimeScale.
I have a table posts (#SQLite), with a string repo (user DID) and int thread_id. Thread_id references the thread root post, around 1/6 of posts have thread_id NULL, the rest are replies. There's an index on repo+time and one on thread_id.
I want to select recent posts from one or more users that have thread_id NULL. But this very smart query planner uses the thread_id index to find posts, even though that will make it check 1/6 of all posts…
A Swift concurrency pattern I’m seeing more and more is the “stateless actor”. This is fascinating, because it seems so counterintuitive. But I think people are reaching for this to get convenient access to background processing.
I don’t think this is “wrong”. But I think it is probably building bad habits. Local, private nonisolated methods are usually simpler and better long-term.
@cocoaphony@mattiem It depends on the situation, but if the whole SwiftUI transaction would be async, you wouldn't necessarily need the loading state.
I'm not 100% positive how this would look like, but that's why Apple has all the smart guys ;-)
Do you have to deal w/ 60k requests per second? Congratulations, you made it! Everyone else is probably going to be happy about 60 (no k) requests per second. Optimise for what you have, not what you dream of. Entirely different requirements.
I provided App Review with email/password combinations for test users to sign in with. Instead of using the provided credentials when reviewing the app, they chose to sign in with a magic link using one of the email addresses, which they don’t have access to.
So now their conclusion is that login doesn’t work in my app and rejected the app 🤦♂️
Any recommendations for open-source Swift packages that provide emojis grouped by category? They can either be a UI component that can be dropped into my app or just the underlying data enabling me to build my own picker.
@simonbs I've built my own before using Emoji-Data, by one of the Slack founders I think 🙂 I converted the JSON file to a static Swift structure representing the info. https://github.com/iamcal/emoji-data
When Swift came out I commented that I thought it was a bad sign that the “community dialogue” went from how to make cool animations to “how do I get the types to work when parsing json”. Ever since ESM (but not just due to ESM), I feel like something similar happened to JS. We’re spending so much time on abstract import bullshit (import maps, mjs, json imports) or typescript compiler blah blah when publishing. This is a natural consequence of the non-app developers leading language development.
@mackuba@dpp@tolmasky The one thing I agree with is that iOS is to be blamed here.
ARC was even in the original Objective-C, it is just saving typing and doesn't solve the issue.
