Re: xlog location arithmetic - Mailing list pgsql-hackers

From Robert Haas
Subject Re: xlog location arithmetic
Date
Msg-id CA+Tgmoav5cWo-VXagnseAhm1kcOzna62dAv9JsAabDK9rUYVKA@mail.gmail.com
Whole thread Raw
In response to Re: xlog location arithmetic  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: xlog location arithmetic  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Dec 23, 2011 at 10:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Dec 23, 2011 at 10:05 AM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Review: Non-inheritable check constraints
Next
From: Tom Lane
Date:
Subject: Re: xlog location arithmetic