On 2019-06-13 08:55, Michael Paquier wrote:
> Speaking about pg_lsn.  We have introduced it to reduce the amount of
> duplication when mapping an LSN to text, so I am not much a fan of
> this patch which adds again a duplication.  You also lose some error
> context as you get the same type of error when parsing the first or
> the second part of the LSN.  Couldn't you refactor the whole so as an
> error string is present as in GUC_check_errdetail()?

There isn't really much more detail to be had.  pg_lsn_in() just reports
"invalid input syntax for type pg_lsn", and with the current patch the
GUC system would report something like 'invalid value for parameter
"recovery_target_time"'.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply via email to