nunwuo

8 ms·

1.
by nunwuo 7y ago
> So if the driver saw yellow and didn't stop then they can't blame that the red light came too fast because they should be stopped already. Huh? Even if you slam your brakes immediately when the light turns yellow, you might
2.
by nunwuo 7y ago
Postgres does this, too; at least to some degree. They call it "synchronized sequential scans".
3.
by nunwuo 10y ago
> If there is one feature I wish PG had, it is recognizing old format db and offering one command that can in place upgrade damn db, without me googling it every time. So your having to Google for five minutes when doing a major version
4.
by nunwuo 10y ago
> Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good. That's not correct. Both Content-Length and the chunked encoding scheme would allow the c
5.
by nunwuo 11y ago
> If the query plan in SQLite looks good, it'll stay good. In a real database, you're sitting on a timebomb waiting to go off when autoanalyze ends up running at a bad time. That's unfortunately naive. For example, for a
6.
by nunwuo 11y ago
> Avoid state at all costs. Stored procedures are stateful. Schema and migrations is pain enough already. What do you mean by that? How is having a bunch of queries in a stored procedure more "stateful" than having the same qu
7.
by nunwuo 11y ago
And how exactly do you think that will corrupt anything?
8.
by nunwuo 11y ago
There are no partial updates in 9.5. There likely never will be in Postgres, due to MVCC.
9.
by nunwuo 11y ago
The good thing about the current name is that there's a clear distinction (at least to users "in the loop") between "psql", the command-line client, and "postgres" the backend service. I'm quite aggr
10.
by nunwuo 11y ago
> Does running the self-pipe trick on a separate thread solve that issue? It seems like it's basically equivalent to signalfd (neither worse nor better, unless you're worried about platform-specific thread bugs): you end up wit
11.
by nunwuo 11y ago
> 1) You're supposed to set the pipe to be non-blocking. Presumably you also then don't check the return code of the write(2) call in the signal handler. While this solves the case of a signal handler blocking forever, it does
12.
by nunwuo 11y ago
That wouldn't change even if there was a specialized syntax, because of MVCC. So the only problem is that syntactic sugar is lacking, not that the performance isn't as good as it could be.
13.
by nunwuo 11y ago
> If we can address fields with operators (->, ->>, etc.) then why can't those operators modify, too? It works for everything else, after all. It's fairly counter-intuitive from a dev perspective. It certainly doesn&#x
14.
by nunwuo 11y ago
There is: logical decoding http://www.postgresql.org/docs/9.4/static/logicaldecoding.ht... I wonder why the author chose to waste time on this instead of doing things the proper way.
15.
by nunwuo 11y ago
"Lone Ranger"
16.
by nunwuo 12y ago
Huh? The entire point of listen/notify is exactly that you don't have to poll.
17.
by nunwuo 12y ago
Untested, but this is the general approach: SELECT unnest(ar).* FROM (SELECT ARRAY(SELECT tbl FROM tbl WHERE .. ORDER BY .. LIMIT 2) AS ar FROM .. OFFSET 0) ss; If you want a specific set of columns instead
18.
by nunwuo 12y ago
There's no faith required; the planner is guaranteed not to do that. The "normal" way is to create a composite type containing each of the columns you need, and then "unpack" it to separate columns. Horrible? Y
19.
by nunwuo 12y ago
That's not true. Anything you can do with LATERAL you can also do with correlated scalar subqueries in the SELECT list. LATERAL simply makes writing these kinds of queries easier and more intuitive.