Skip site navigation (1) Skip section navigation (2)

Re: xlog location arithmetic

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog location arithmetic
Date: 2011-12-23 11:54:22
Message-ID: CABUevEyXUZ=-wONOw-vEaXsrhCS80v1Y4_hN7xWOPAJ8LfTFaA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Dec 20, 2011 at 14:08, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> wrote:
> On 20-12-2011 07:27, Magnus Hagander wrote:
>> On Tue, Dec 6, 2011 at 19:06, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
>>> <euler(at)timbira(dot)com> wrote:
>>>> On 06-12-2011 13:11, Robert Haas wrote:
>>>>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>>>> I've been considering similar things, as you can find in the archives,
>>>>>> but what I was thinking of was converting the number to just a plain
>>>>>> bigint, then letting the user apply whatever arithmetic wanted at the
>>>>>> SQL level. I never got around to acutally coding it, though. It could
>>>>>> easily be extracted from your patch of course - and I think that's a
>>>>>> more flexible approach. Is there some advantage to your method that
>>>>>> I'm missing?
>>>>>
>>>>> I went so far as to put together an lsn data type.  I didn't actually
>>>>> get all that far with it, which is why I haven't posted it sooner, but
>>>>> here's what I came up with.  It's missing indexing support and stuff,
>>>>> but that could be added if people like the approach.  It solves this
>>>>> problem by implementing -(lsn,lsn) => numeric (not int8, that can
>>>>> overflow since it is not unsigned), which allows an lsn => numeric
>>>>> conversion by just subtracting '0/0'::lsn.
>>>>>
>>>> Interesting approach. I don't want to go that far. If so, you want to change
>>>> all of those functions that deal with LSNs and add some implicit conversion
>>>> between text and lsn data types (for backward compatibility). As of int8, I'm
>>
>> As long as you have the conversion, you don't really need to change
>> them, do you? It might be nice in some ways, but this is still a
>> pretty internal operation, so I don't see it as critical.
>>
> For correctness, yes.
>
> At this point, my question is: do we want to support the lsn data type idea or
> a basic function that implements the difference between LSNs?

Personally I think a function is enough - it solves the only case that
I've actually seen. But a datatype would be a more complete solution,
of course - but it seems a bit of an overkill to me. Not really sure
which way we should go - I was hoping somebody else would comment as
well..

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

pgsql-hackers by date

Next:From: Marc MaminDate: 2011-12-23 12:06:20
Subject: Another hstore_type idea
Previous:From: Dimitri FontaineDate: 2011-12-23 11:39:40
Subject: Re: reprise: pretty print viewdefs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group