On 4 November 2016 at 10:04, Michael Paquier <michael.paquier@gmail.com> wrote:
> On Tue, Nov 1, 2016 at 11:31 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I liked Heikki's suggestion (at some point quite a while ago now) of
>> recovery_target = 'xid 123' or recovery_target='lsn 0/723' or
>> whatever.
>
> My vote goes for having two separate parameters, because as we know
> that there will be always two fields in this parameter, there is no
> need to complicate the GUC machinery with a new special case when
> parsing its value. Having two parameters would also make easier the
> life of anybody maintaining a library parsing parameters for values
> and doing in-place updates of those values. For example, I maintain a
> set of routines in Python doing that with some fancy regex routines,
> and that would avoid having to handle a special case when willing to
> update for example the same recovery target with a new value.
Parameters are required to all make sense independently, so two
parameters is off the table, IMHO.
The choice is one parameter, as Robert mentions again, or lots of
parameters (or both of those).
Since the "lots of parameters" approach is almost exactly what we have
now, I think we should do that first, get this patch committed and
then sit back and discuss an improved API and see what downsides it
introduces. Further delay on this isn't helpful for other patches
going in.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services