812 karma · joined October 3, 2020
A preprint of the paper is available here: https://web.archive.org/web/20250708141740/https://www.ics.u...
edit: I guess an easy fix is to append a cryptographic hash to the post ID, but yeah currently I'm assuming you trust your friends.
2. You don't need to know unless you want to implement the protocol! To use (the very barebones) implementation all you need to do is fork the repo & give access, which I admit can be too much for family/friends so you might have to set it up for them (and I bet they'd be stoked to have a website of their own!)
If you know the [gemtext][1] format for the [gemini][2] protocol, md0 is basically that but supports inline links and happens to also be valid markdown. Oh, and this post is also valid md0. You can see it in action on [Playdate][3] here:
![md0 on Playdate][4]
[1]: https://geminiprotocol.net/docs/gemtext-specification.gmi [2]: https://en.wikipedia.org/wiki/Gemini_(protocol) [3]: https://play.date [4]: https://github.com/remysucre/ORBIT/blob/main/demo.gif
That leads to an even more confusing point, that some systems (at least SQLite) overloads NULL to mean UNKNOWN, for example `SELECT 1 WHERE NULL = (NULL = NULL)`.
And the dangerous thing about NULLs is not when they are explicitly used in the query as a literal (as I did for brevity), but when they appear in tables. It's perfectly reasonable to assume `SELECT COUNT( * ) FROM t;` should be the same as `SELECT COUNT( * ) from t WHERE t.x = t.x OR t.x <> t.x`, but they are not the same because the latter does not return NULL rows. This has lead to real query optimizer bugs. For more examples see this paper https://dl.acm.org/doi/10.14778/3551793.3551818
A data expression always evaluates to a data value, and usually whenever any part of the expression is NULL, the entire expression evaluates to NULL.
A comparison evaluates to a truth value, and usually when a comparison invovles a NULL it returns UNKNOWN. This leads to weird behaviors where both `SELECT 3 WHERE NULL = NULL;` and `SELECT 3 WHERE NULL <> NULL;` returns nothing (because the query engine does not output a row if the predicate returns UNKNOWN on it).
What you listed above only comes into play for boolean/logical connectives like AND, OR, NOT, and in that case we follow 3-valued logic.
And there's more annoying corner cases when you deal with DISTINCT. The situation is so hopeless that SQLite has a whole table documenting divergent behaviors of NULL in different systems: https://www.sqlite.org/nulls.html
> Just use sqldiff
sqldiff is sensitive to ordering, e.g., it'll say the relation [1, 2] is different from [2, 1] (I consider them to be the same because they are the same multiset). You'd need to sort with ORDER BY first, but that also requires listing all attributes explicitly like the GROUP BY solution (ORDER BY * doesn't work).
> What about CHECKSUM
It's also sensitive to ordering, and I was told different tables can have the same CHECKSUM (hash collisions?).
> Are the tables the same if they only differ by schema?
I'd say no. Perhaps a better definition of "the same" is that all SQL queries (using "textbook" SQL features) return the same result over the tables, if you just replace t1 with t2 in the query. Wait, but how do you know if the results are the same... :)
> There are better ways to compare tables
Absolutely, my recursive query runs in time O(N^N) so I'm sure you can be a little better than that.