On 2 May 2013 08:31, Magnus Hagander <mag...@hagander.net> wrote: > That said, there is one property that's very unclear now and that's > that you can only set one of recovery_target_time, recovery_target_xid > and recovery_target_name. But they can be freely combined with > recovery_target_timeline and recovery_target_inclusive. That's quite > confusing.
In the docs we say "At most one of recovery_target_time, recovery_target_name or recovery_target_xid can be specified." on each of those parameter descriptions. In recovery.conf.sample, we say # You may set a recovery target either by transactionId, by name, # or by timestamp. Recovery may either include or exclude the # transaction(s) with the recovery target value (ie, stop either # just after or just before the given target, respectively). Who is confused by that? And if they are, why would they be less confused with changed *syntax*? I think most people just copy the examples anyway, they don't care about the syntax. As we just saw, changing the syntax may introduce other consistency issues and confusions that weren't there before. If the precise syntax is the essence of a new and improved interface, surely it needs to be fully worked out before anybody agrees. It has always been the case that recovery is a complex topic and one that is used in stressful circumstances. It isn't the syntax that makes using this hard, its the fact that the process itself is non-trivial and not easy to use without some prior thought and testing of how recovery will work for a particular company/enterprise. I'm very progressive about both new features and usability improvements, but rearranging things for minor reasons just feels like a waste. If we feel strongly about user interface design problems we should treat them the same way we treat performance issues. Profile to identify problem areas, analyze problems in those areas and suggest solutions, then make tests to check that the new interface genuinely works better than the old. That is proper UI improvement, not just knee jerk reactions. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers