Re: should we add a XLogRecPtr/LSN SQL type?

On 2013-12-11 08:13:18 -0500, Robert Haas wrote:
> On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > There's already a couple of SQL function dealing with XLogRecPtrs and
> > the logical replication work will add a couple of more. Currently each
> > of those funtions taking/returning an LSN does sprintf/scanf to
> > print/parse the strings. Which both is awkward and potentially
> > noticeable performancewise.
> >
> > It seems relatively simple to add a proper type, with implicit casts
> > from text, instead?
>
> I'm pretty sure that this was discussed last year, and I voted for it
> but more people
> voted against it, so it died. I still think that was a mistake, but I
> just work here.

Ah. I missed or forgot that discussion. The primary argument seemed to
be that we were are only talking about a single function using it. I
don't think that really was true back then, but there definitely are
some more uses coming up. E.g. the changeset extraction SRF will return
the LSN of every extracted change...
I don't really buy the argument that it can wholl be replaced by
representing LSNs as numeric - those look significantly different enough
that that doesn't seem to make much sense to me. Also, they are a
pass-by-reference type...

> -- except for the implicit casts part, perhaps --

I'd like to convert some existing functions to use the new type, and
without added casts that seems too likely to break existing usages. If
we just consistently use the new type everywhere, I can't see the usual
troubles with the added casts.

On 2013-12-11 10:13:51 -0300, Euler Taveira wrote:
> On 11-12-2013 09:41, Andres Freund wrote:
> While discussing pg_xlog_location_diff function, Robert posted a lsn
> datatype [1]. At that time we wouldn't go that far (a new datatype) to
> cover only one function. If your proposal is just validation, I think
> generic validation functions is the way to follow. However, if you are
> thinking in adding operators, the lsn datatype should be implemented.

I am mostly thinking of returning many such datums - representing them
as text is just pointless overhead. But even if it just were validation
- why sprinkle validation over dozens of places if we actually have a
typesystem to handle that kind of thing?

> > It seems relatively simple to add a proper type, with implicit casts
> > from text, instead?
> Do you want to change the function signatures too?

Yes.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services