Re: should we add a XLogRecPtr/LSN SQL type?
От | Michael Paquier |
---|---|
Тема | Re: should we add a XLogRecPtr/LSN SQL type? |
Дата | |
Msg-id | CAB7nPqQfOuxUC5n33iqu8dAQCRMim3kPwYS-Fmzx3PKzXyF8mg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: should we add a XLogRecPtr/LSN SQL type? (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: should we add a XLogRecPtr/LSN SQL type?
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: