Re: Function for dealing with xlog data

Currently, a number of functions return data in a really
calculation-unfriendly format, e.g:

postgres=# select * from pg_current_xlog_location();
pg_current_xlog_location
--------------------------
0/3013158
(1 row)

It would be very useful to have a way to convert this to a bigint - so
we can do differences between different values easily. And it's AFAIUI
easily converted to a 64-bit integer.

Would others find this useful as well?

What's the best way of doing it? Should we have a function that takes
text as input, or should the functions in question be made to return a
new datatype that could then be casted?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Currently, a number of functions return data in a really
> calculation-unfriendly format, e.g:
>
> postgres=# select * from pg_current_xlog_location();
>  pg_current_xlog_location
> --------------------------
>  0/3013158
> (1 row)
>
> It would be very useful to have a way to convert this to a bigint - so
> we can do differences between different values easily. And it's AFAIUI
> easily converted to a 64-bit integer.
>
> Would others find this useful as well?

Yes.

> What's the best way of doing it? Should we have a function that takes
> text as input, or should the functions in question be made to return a
> new datatype that could then be casted?

The new datatype seems more elegant, but a conversion function would
be a lot less work.

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

On Tue, Dec 28, 2010 at 14:39, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> Currently, a number of functions return data in a really
>> calculation-unfriendly format, e.g:
>>
>> postgres=# select * from pg_current_xlog_location();
>>  pg_current_xlog_location
>> --------------------------
>>  0/3013158
>> (1 row)
>>
>> It would be very useful to have a way to convert this to a bigint - so
>> we can do differences between different values easily. And it's AFAIUI
>> easily converted to a 64-bit integer.
>>
>> Would others find this useful as well?
>
> Yes.
>
>> What's the best way of doing it? Should we have a function that takes
>> text as input, or should the functions in question be made to return a
>> new datatype that could then be casted?
>
> The new datatype seems more elegant, but a conversion function would
> be a lot less work.

Well, yeah, that was obvious ;) The question is, how much do we prefer
the more elegant method? ;)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010:
> On Tue, Dec 28, 2010 at 14:39, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> >> What's the best way of doing it? Should we have a function that takes
> >> text as input, or should the functions in question be made to return a
> >> new datatype that could then be casted?
> >
> > The new datatype seems more elegant, but a conversion function would
> > be a lot less work.
>
> Well, yeah, that was obvious ;) The question is, how much do we prefer
> the more elegant method? ;)

If we go the new type route, do we need it to have an implicit cast to
text, for backwards compatibility?

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010:
>> Well, yeah, that was obvious ;) The question is, how much do we prefer
>> the more elegant method? ;)

> If we go the new type route, do we need it to have an implicit cast to
> text, for backwards compatibility?

I'd argue not. Probably all existing uses are just selecting the
function value. What comes back to the client will just be the text
form anyway.

I'm of the opinion that a new type isn't worth the work, myself,
but it would mostly be up to whoever was doing the work.

regards, tom lane

On Tue, Dec 28, 2010 at 16:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010:
>>> Well, yeah, that was obvious ;) The question is, how much do we prefer
>>> the more elegant method? ;)
>
>> If we go the new type route, do we need it to have an implicit cast to
>> text, for backwards compatibility?
>
> I'd argue not.  Probably all existing uses are just selecting the
> function value.  What comes back to the client will just be the text
> form anyway.

That's certainly the only thing I've seen.

> I'm of the opinion that a new type isn't worth the work, myself,
> but it would mostly be up to whoever was doing the work.

Fair enough - at least enough people have said it won't be rejected
because it's done as a function rather than a datatype - so that seems
like the easiest way to proceed.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/