sorkin2

While admittedly this could be seen as a mistake in SQL, you can differentiate by looking at whether b.id is NULL or not.

That's a "cure" worse than the disease.

What kind of official support?

Tough.

The same way the new built-in logical replication works: logical decoding.

Really hasn't been in years. I've not even heard of anyone using it in over a year. But I mostly speak with people who stream video games.

> One kind of significant downside of partial indexes in PostgreSQL is that they don't work with parameters.

Your example is fundamentally different from parameters sent by a client in a parameterized query, i.e. $1, $2, etc. Also while your flawed example will never use a partial index, parameterized queries can and often will do that. With prepared statements (which are a slightly different concept from parameterized queries) the devil will lie in the details, but even those don't really prevent partial indexes from being used since postgres version 9.2, released years ago.

> Changing from master to replica is easy, but now you have to rebuild that original master off of the former replica now. Completely start over. You can't just start up again from a given transaction ID. MySQL's GTID implementation is much better in this regard. You can change masters and replicas all repoint them without rebuilding. You can't do that (currently) with Postgresql.

Have you heard of pg_rewind? https://www.postgresql.org/docs/current/static/app-pgrewind....

> They maintained a replication process across both tables as they updated the read processes before updating the write process. Say for whatever reason their offline replication process broke for 2 hours.

From the article I got the impression that both tables were being written to in the same database transaction, so this is not a possible failure scenario at all.

This kind of nannying can be really expensive to do correctly when trying to build high performance systems -- to the point where it doesn't make sense to punish everyone just because someone who didn't read the manual MIGHT misuse the product. It's not at all unreasonable to mix transactions with different guarantees if they never touch the same data, and tracking that accurately enough without pissing off your customers with performance needs seems like a fool's errand.

Hmm.. So was there a workflow where I could say "I'd like for this not to be pushed until I've approved it", even if the patch is assigned to be reviewed by someone else? Of course, I could just comment with that on the issue, but it would be nicer if the issue would pop up somehow after the other reviewer has reviewed it, and it would be obvious to everyone that it's waiting for my approval.