Only if your developers are inexperienced.
HN user
trinitry3
Did we just seriously compare coffee to meth?
You can use -P.
Nothing to do with CTEs. The queries were badly written to begin with and should have used LATERAL.
I have a recurring dream where my teeth are glued shut but for whatever reason I have to open my mouth, ripping all my teeth out.
She could just say that to every patient and she'd be right most of the time ;-)
Why should any government incentivize that?
Well maybe they shouldn't, but it's shitty to apply this kind of policy retroactively. (I don't know when they actually announced the fact that you can't deduct losses.)
This is really bad advice:
1) This is not really a temporary table in the traditional
sense; you're creating a real table and then dropping it.
This has problems with concurrency (you can't have two
"real" tables with the same name), among other issues.
2) Temporary tables in Postgres suck because they bloat
the catalogs. Creating temporary tables regularly is
better avoided.
3) There's no real need to create a table of any kind. A
regular VALUES would do. (Though you might have to encode
some type information into the query.)Relating to wallhacks, they can use your last 1,000 matches, and if you're never/rarely surprised by a camping enemy, you're probably cheating. Your camera position moments before interaction with an obscured enemy is probably another indicator.
Do you actually play CS:GO proficiently? Because it doesn't sound like you do.
Say I wanted to present a list of users with their top three to-do items, that's impossible using the above method.
Not really:
SELECT u.user, i.text
FROM users u,
LATERAL (SELECT * FROM items WHERE items.user = u.user ORDER BY items.pos DESC LIMIT 3) i;
(You can also make these columns instead of rows, but as someone already pointed out, you'd usually not do that in SQL.)There was a patch for fixing #1 with new syntax for the next version on the mailing list, so perhaps in a year this'll get fixed?