Re: should we add a XLogRecPtr/LSN SQL type?
От | Robert Haas |
---|---|
Тема | Re: should we add a XLogRecPtr/LSN SQL type? |
Дата | |
Msg-id | CA+TgmoatbE1U3GKD=KXC_rvVFucTowW0fXuu+BA0ZNdjzYNHMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: should we add a XLogRecPtr/LSN SQL type? (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On Wed, Feb 19, 2014 at 8:06 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > 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, committed. But I left out the whitespace change you included. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: