On 26 April 2013 18:13, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > On 26.04.2013 19:50, Magnus Hagander wrote: >> >> On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs<si...@2ndquadrant.com> >> wrote: >>> >>> On 26 April 2013 17:25, Heikki Linnakangas<hlinnakan...@vmware.com> >>> wrote: >>>> >>>> Actually, from a usability point of view I think would be nice to have >>>> just >>>> >>>> one setting, "recovery_target". It's already somewhat confusing to have >>>> recovery_target_xid, recovery_target_time, and recovery_target_name, >>>> which >>>> are mutually exclusive, and recovery_target_inclusive which is just a >>>> modifier for the others. Maybe something like: >>>> >>>> recovery_target = 'xid 1234' >>>> recovery_target = 'xid 1234 exclusive' >>>> recovery_target = '2013-04-22 12:33' >>>> recovery_target = '2013-04-22 12:33 exclusive' >>>> recovery_target = 'consistent' >>>> recovery_target = 'name: daily backup' >>> >>> >>> So now you want to change the whole existing API so it fits with your >>> one new requirement? > > > No, I think the above would be a usability improvement whether or not we add > the new feature.
I don't see the usability improvement. This is only being suggested to make one new addition look cleaner; there isn't a common gripe that the use of parameters is hard to use, other than their location and the ability to treat them as GUCs. This changes the existing API which will confuse people that know it and invalidate everything written in software and on wikis as to how to do it. That means all the "in case of fire break glass" instructions are all wrong and need to be rewritten and retested. It also introduces a single common datatype for such entries, where before we had that xids were numbers, names were text, so this new mechanism operates completely differently from all other GUC parameters. Plus its inconsistent, in that with xids you have 'xid 1234' whereas timestamps just say '2013-04-22' rather than 'timestamp 2013-04-22', or with names should they end in a colon or not. There'n no clear differentiation between text for names and other keywords. Presumably we'll need a complex parser to sort that out. When we add a new feature that requires a new format, will we change the whole format again to make that fit in also? -- 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