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

Re: xlog location arithmetic

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog location arithmetic
Date: 2011-12-23 15:32:29
Message-ID: CA+Tgmoav5cWo-VXagnseAhm1kcOzna62dAv9JsAabDK9rUYVKA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I too think a datatype is overkill, if we're only planning on providing
>>> one function.
>
>> Are there any other functions we ought to provide?
>
> Even if there are several, what exact advantage does a datatype offer
> over representing LSN values as numerics?  It seems to me to be adding
> complication and extra code (I/O converters at least) for very little
> gain.

I guess I'm just constitutionally averse to labeling things as "text"
when they really aren't.  I do it all the time in Perl, of course, but
in PostgreSQL we have strong data typing, and it seems like we might
as well use it.

Also, we've occasionally talked (in the light of Pavan's single-pass
vacuum patch, for example) about needing to store LSNs in system
catalogs; and we're certainly not going to want to do that as text.
I'll admit that it's not 100% clear that anything like this will ever
happen, though, so maybe it's premature to worry about it.

I can see I'm in the minority on this one, though...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-12-23 15:59:35
Subject: Re: xlog location arithmetic
Previous:From: Robert HaasDate: 2011-12-23 15:27:32
Subject: Re: Review: Non-inheritable check constraints

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