Real Talk. The most powerful design tool I use on a regular basis is the .border(.red) modifier in SwiftUI. The ability to quickly examine a view's bounds IN CONTEXT has always been super useful to diagnose weird layout bugs, fix alignment and correct visual spacing.
@_Davidsmith Another nice trick is using a random (or incrementing) color from a set (instead of a static one like red). This way you can visualize view refreshes.
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…