On Tue, Dec 6, 2011 at 19:06, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
> <euler@timbira.com> wrote:
>> On 06-12-2011 13:11, Robert Haas wrote:
>>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander <magnus@hagander.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.
>> not aware of any modern plataform that int8 is not 64 bits. I'm not against
>> numeric use; I'm just saying that int8 is sufficient.
>
> The point isn't that int8 might not be 64 bits - of course it has to
> be 64 bits; that's why it's called int8 i.e. 8 bytes. The point is
> that a large enough LSN, represented as an int8, will come out as a
> negative values. int8 can only represent 2^63 *non-negative* values,
> because one bit is reserved for sign.
Doing it in numeric should be perfectly fine. The only real reason to
pick int8 over in this context would be performance, but it's not like
this is something that's going to be called in really performance
critical paths...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
