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 по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: Priority table or Cache table
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding