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
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.
-- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
