| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: check_recovery_target_lsn() does a PG_CATCH without a throw |
| Date: | 2019-06-13 07:04:15 |
| Message-ID: | 0f1d0395-cfcd-5f4a-a5ff-38aa17cb63ac@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2019-06-13 07:16:29 | Re: Update list of combining characters |
| Previous Message | Michael Paquier | 2019-06-13 06:55:37 | Re: check_recovery_target_lsn() does a PG_CATCH without a throw |