Re: should we add a XLogRecPtr/LSN SQL type? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: should we add a XLogRecPtr/LSN SQL type?
Date
Msg-id CAB7nPqRc7u6-81Az+vz3e7_ZyK+ii3dEqtvCATZdrs=EEj_xEw@mail.gmail.com
Whole thread Raw
In response to Re: should we add a XLogRecPtr/LSN SQL type?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: should we add a XLogRecPtr/LSN SQL type?  (Andres Freund <andres@2ndquadrant.com>)
Re: should we add a XLogRecPtr/LSN SQL type?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: should we add a XLogRecPtr/LSN SQL type?
Next
From: Tom Lane
Date:
Subject: Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)