Re: check_recovery_target_lsn() does a PG_CATCH without a throw
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
Tom Lane <tgl@sss.pgh.pa.us>
Date: 2019-06-13T07:04:15Z
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
Commits
-
Don't call data type input functions in GUC check hooks
- 21f428ebde39 12.0 landed