> 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…
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…
> 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…
> 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…
> 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…
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…
> 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…
> 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,…
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…
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; If you want a specific set of columns instead of *, you'd…
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…
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.
> 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…
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…
> 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…
> 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…
> 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…
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…
> 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…
> 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,…
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…
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; If you want a specific set of columns instead of *, you'd…
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…
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.