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 CAB7nPqTgMfM_cMJcD85FAOVt=ofTdF58OGpT=JBAaDwJy_YtfQ@mail.gmail.com
Whole thread Raw
In response to Re: should we add a XLogRecPtr/LSN SQL type?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: should we add a XLogRecPtr/LSN SQL type?  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Thu, Feb 20, 2014 at 2:47 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> On 2/5/14, 1:31 PM, Robert Haas wrote:
>>>> On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>>>> Perhaps this type should be called pglsn, since it's an
>>>>> implementation-specific detail and not a universal concept like int,
>>>>> point, or uuid.
>>>>
>>>> If we're going to do that, I suggest pg_lsn rather than pglsn.  We
>>>> already have pg_node_tree, so using underscores for separation would
>>>> be more consistent.
>>>
>>> Yes, that's a good precedent in multiple ways.
>> Here are updated patches to use pg_lsn instead of pglsn...
>
> OK, so I think this stuff is all committed now, with assorted changes.
>  Thanks for your work on this.
Thanks!
Oops, it looks like I am coming after the battle (time difference does
not help). I'll be more careful to test such patches on 32b platforms
as well in the future.
Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Priority table or Cache table
Next
From: Michael Paquier
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Add a GUC to report whether data page checksums are enabled.