Re: Cascading replication: should we detect/prevent cycles?

On 01/28/2013 02:13 AM, Robert Haas wrote:
> If we're going to start installing safeguards against doing stupid
> things, there's a long list of scenarios that happen far more
> regularly than this ever will and cause far more damage.
I'm not sure this approach is consistent with other decisions made in
the past, and with the project's general goals of stability and quality.

In particular, by the above rationale, why would the project have for
8.3 removed the implicit casts to/from 'text'? It's a minor safeguard
against users doing stupid things. Many other such safeguards exist -
and despite my frustration with some details of the implicit casts,
overall I think that such safeguards are a good and desirable thing.

Safeguards to stop users doing stupid things are part of good usability,
so long as they do not interfere excessively with performance,
functionality, maintainability, etc. Even where data loss/corruption is
not a risk, if it's feasable to detect a misconfiguration, bad command,
etc, IMHO it generally makes sense to do so. Otherwise we land up in
MySQL-land, littered with foot-guns, quirks, features that are easy to
misconfigure and hard to tell if they're misconfigured (PITR and
streaming replication are already in that category IMO), and generally
get a reputation as being hard to use, hard to troubleshoot, and painful.

I don't mean to be contrary; I realise that I've raised a differing view
a fair bit recently, but I'm only doing so when I think there's
something to contribute by doing so. Posting a "me too" when I agree is
rather less helpful, so its the differing views that tend to actually
get posted, despite being in the minority.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services