Yeah at that point I think we'd be better off if everything was just UTC and dealt with locally

> Per the SQL standard, you can't use column aliases in WHERE clauses, because the selection (again, relational algebra) occurs before the projection.

Except this works in most major vendor SQL implementations. And they all support relation aliases in SELECT... Seems the standards have long fell behind actual implementations.

To clarify, I mean you can’t do this:

    SELECT id AS foo
    FROM MyTable
    WHERE foo = 1;

Similarly, you can’t do this:

    SELECT id
    FROM MyTable
    WHERE id = MAX(id);

Because in both cases, when the WHERE predicate is being executed, the engine doesn’t yet know what you’re asking it to find - for the former, SELECT hasn’t yet been called, so the alias isn’t applied; for the latter, the aggregation happens after filtering, so it can’t know what that maximum value is.

You can of course alias columns for SELECT however you’d like, and can also use those aliases in ORDER BY. You can also trivially refactor the above examples to use subqueries or CTEs to accomplish the goal.

You absolutely can in many engines, for instance in Snowflake... with the small exception that in all supporting engines you actually need to use HAVING instead of WHERE in your second example (because it compares an aggregation, otherwise WHERE is fine).

You can also use "correlated column aliases" (I can't recall the proper name) i.e.

    SELECT
        id AS foo,
        foo || '_1' as foo_n,
        right(foo_n, 1) as foo_ordinal
    FROM MyTable
    WHERE foo = 1;

Again, if this isn't all part of SQL standards, the reality is that a lot of engines have semi-standard (sometimes very proprietary too) ways of handling these now common patterns. For real-world use cases, the standards are unfortunately becoming increasingly irrelevant. I think it would be better in the long term to use standards, but if they can't keep up with actual usage then they will just get ignored.

You apparently can in SQLIte though: https://sqlfiddle.com/sqlite/online-compiler and query:

    SELECT LOWER(Name) as LName FROM Product where LName like '%frame%';

Some factors I think are involved, but I don't see mentioned - EVs produce more readily available torque in general, and also tire choice heavily factors in EV range (low rolling resistance), which has a negative impact on tread life

We make corn that isn't even considered a food, legally. We subsidize that using a lot of tax dollars, to the absurd point that we pay farmers to NOT grow corn and leave fields empty. Everyone is paying for way more corn than is needed through taxes, while people claim this keeps costs low (it's more, you are just paying it in taxes). And then we come up with excuses to use more of it, like corn syrup and ethanol. This is absolutely absurd.

I think it is considered a strategic defense resource. Imagine we end up with a WWIII consisting of dozens of proxy wars where the nuclear powers carefully avaoid direct action on eachothers soils to avoid the war going nuclear. International food, oil, materials and goods shipments would be severely curtailed. Corn can be used to produce, sugars, oil, and alcohol and biomass for fuel, food, and chemical feedstock for plastic manufacturing. While there are better sources for any of those not many can do all of them and be easily grown in mass in our own backyard

I don't understand your point about "legally considered food". If the corn is used to produce corn syrup, it's legally food; if it's not, it has some other purpose, and I don't know why I should care.

Long before the richest man on earth bought Twitter to be his personal megaphone to help him prepare to become president in order to boost all his personal endeavors, the letter X has been used as a sort of contraction to replace common morphemes like "cross", "trans" etc, in places where the physical representation "x" likens to a cross or crossing of some sort, or in reference to the Greek letter Chi. Must we change our use of language to support this guy, too?

Xtian Xmas xfer tx/rx xor...

You pretty much listed all the examples where that’s done (x-ing is also a big one, on signs), but there are way more cases where no one would ever use the letter X like that. I think parsing that kind of “syntax sugar” takes more cycles than a lot of people care to spare just to understand what a stranger is saying online. It’s too loose to be commonly applicable. Things like “Xmas” are accepted on a case by case basis.

The argument wasn’t made out of principle, either. If it were more widespread, it would be worth the potential confusion. It’s just not. I agree with that.

I don't think "xor" belongs to that list, given that the "x" in it is a shortening of "eXclusive".

You need to be a natural-born citizen to become US president. Musk was born in South Africa.

I believe the "thinking out loud" is fundamentally part of the process of "text completion" which is what it is doing. Certainly we can (and do) break things apart and add layers that could be used to effectively do this by adding more steps and processing time. But ultimately in a single turn, the entire conversation up to that point (including instructions you may have added telling it to not think out loud) is the input, and the output will reflect that.

I'm not arguing your point, but this is the general state of gaming today. A significant portion of "single player only" games require you to be online, contain "online" content, and access to the game can/will be effectively removed when servers/services go offline.

It's a sad state of affairs that you can buy an offline game, and then the developer/publisher can push out an update that turns it into an online game and then disables your access to it

It's sad, but people keep buying these games, so there is no incentive for the game companies to stop.

What's the practical benefit over just sharding a decryption key and handing out multiple shards to each person?

1. You need all the shards of the key to decrypt the text instead of just reaching a threshold.

2. The full encrypted text is available to each person, making it vulnerable to a brute force attack at some point in the far future.

I'm not entirely sure if this implementation actually covers that second point though. It could be including the entire encrypted text with each copy. But it would theoretically be possible to protect against brute force attacks in that way.

The second point, yeah that's relevant.

On the first point, just give each person n-1 shards, each missing a different one. Then any 2 can decrypt. Or configure it for however many participants there are and they minimum number needed to encrypt.

The key part about Shamir is that having any number of shards short of the threshold doesn't reveal anything about the secret. Let's say you split your 256 bit encryption key into 4 64-bit pieces with each person getting 3 of the 4. Each person now knows 3/4 of the secret. Now any one person simply has to brute force the remaining 64 bits of the key in order to decrypt.

for something a bit more robust, check out DuckDB. It's a library you can embed, use it to run SQL on local files as well as connect to databases, do joins, analytics, etc.

Agreed. The article mentioned duckdb and I'm her to thumbs-up the use of DuckDB wholeheartedly. If you like the world of public CSV files as data sources that you can query or cross-query, duckdb is the tool for you. Just follow the demo on the duckdb website and you'll be wow'd for sure.

I use both, and I have found it helpful to have nushell around when munging csv and parquet files, even when working with duckdb - I find it quicker to ask for the first few rows of a thing or do simple stuff with it, then deeper analysis with duckdb.

They're a powerful pairing