nunwuo

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 not stop on time if the yellow light is only on for, say, 100 milliseconds if you were close enough to the intersection.

This isn't at all as simple as you make it out to be, and the article made a pretty good point.

Postgres does this, too; at least to some degree. They call it "synchronized sequential scans".

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 upgrade is the biggest flaw in modern postgres? Oh come on now.

P.S. pg_upgradecluster in Debian would probably do this for you without googling

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 client to know that the connection was terminated before the end of stream was reached.

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 certain type of query there are two possible plans. Which one is better depends on the parameters to the plan and the distribution of the data, and getting the plan wrong can be the difference between the query finishing and the query not finishing. With a stability guarantee you can't even try to make an intelligent choice based on the parameters.

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 queries in the application?

Write me a check constraint that validates an email address being put in a varchar column and reports back a sensible message which can be bound to an entry field with metadata about the error.

Postgres gives you metadata about the error, though the error message will still be a generic "CHECK constraint violated" or some such.

Write me a constraint and key arrangement which is unique across two and three columns in separate groups.

I'm not sure what you want to see based on that description, but surely you're not advocating enforcing unique constraints in the application?

And how exactly do you think that will corrupt anything?

There are no partial updates in 9.5. There likely never will be in Postgres, due to MVCC.

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 aggressively against renaming the product to "psql".

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 with a signal mask on your main thread, but you also avoid EINTR on your main thread. Any possible pipe lockup just happens on the signal-handling thread, so the mainloop can keep running and eventually dequeue signals.

There's no need for threads. Set the pipe to non-blocking and ignore the write() error if it's EAGAIN/EWOULDBLOCK. See my response above for why dropping writes if a byte already exists in the pipe is okay.

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 mean you might have dropped writes that correspond to signal receptions.

That doesn't matter. You're not supposed to have a byte in the pipe for every signal. What matters is having at least one byte any time there are unprocessed signals. The only function of the pipe is to wake the select(2) up. You still need bookkeeping elsewhere.

That leads us to:

2) The self-pipe trick specifically calls out handling SIGCHLD (probably because it's one signal that you don't want to ignore!) But given the chances of dropping a byte as described in 1) and the fact that SIGCHLD and fork are explicitly called out, I can only assume that the lesson here is: only have one pipe per signal you intend to handle. Since multiple signals sent to a process may result in a single signal being delivered, your real signal handling code (the stuff that's watching the other end of the pipe) already has to deal with this situation.

Meh. Just have one pipe and a sig_atomic_t for each different types of signal you're interested in.

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.

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't work for "everything else". You can update individual "parts" of arrays and record types, that's it. And those exception are hard-coded, so someone would either have to hard-code similar exceptions for JSON values (ugly, inflexible, generally a bad idea) or generalize support for custom operators on the left-hand side of assignments in UPDATE. All this while trying to push out a release which was already late by months.

You can call everything an oversight, but with very limited resources available and the need to cut a release at some point, this is far from the truth in this case.

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.

"Lone Ranger"

Huh? The entire point of listen/notify is exactly that you don't have to poll.

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;

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? Yeah, but it's possible.

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.