Re: should we add a XLogRecPtr/LSN SQL type?

On Tue, Feb 4, 2014 at 10:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> Please find attached a patch implementing lsn as a datatype, based on
>> the one Robert wrote a couple of years ago.
>
>> Patch contains regression tests as well as a bit of documentation.
>> Perhaps this is too late for 9.4, so if there are no objections I'll
>> simply add this patch to the next commit fest in June for 9.5.
>
> I may have lost count, but aren't a bunch of the affected functions new
> in 9.4?  If so, there's a good argument to be made that we should get
> this in now, rather than waiting and having an API change for those
> functions in 9.5.
Cool... I have created a second patch that updates all the system
functions to use the new lsn datatype introduced in the 1st patch
(pg_start|stop_backup, replication_slot stuff, xlog diff things, etc.)
and it is attached. This cleans up quite a bit of code in xlogfuncs.c
because we do not need anymore the LSN <-> cstring transformations!
I am also attaching a v2 of the first patch, I noticed that lsn_in
introduced in the first patch was using some error messages not
consistent with the ones of validate_xlog_location:xlogfuncs.c. Note
as well that validate_xlog_location is removed in the 2nd patch where
all the system functions are swicthed to the new datatype.
Regards,
--
Michael