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 CAB7nPqQfOuxUC5n33iqu8dAQCRMim3kPwYS-Fmzx3PKzXyF8mg@mail.gmail.com
Whole thread Raw
In response to Re: should we add a XLogRecPtr/LSN SQL type?  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: should we add a XLogRecPtr/LSN SQL type?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Feb 20, 2014 at 9:43 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> 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.
After re-reading the code, I found two incorrect comments in the new
regression tests. Patch fixing them is attached.
Thanks,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: Priority table or Cache table
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding