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

On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
>>> I'm not, however, terribly thrilled with the suggestions to add implicit
>>> casts associated with this type.  Implicit casts are generally dangerous.
>
>> It's a tradeof. Currently we have the following functions returning LSNs
>> as text:
>> * pg_current_xlog_location
>> * pg_current_xlog_insert_location
>> * pg_last_xlog_receive_location
>> * pg_last_xlog_replay_location
>> one view containing LSNs
>> * pg_stat_replication
>> and the following functions accepting LSNs as textual paramters:
>> * pg_xlog_location_diff
>> * pg_xlogfile_name
>
>> The question is how do we deal with backward compatibility when
>> introducing a LSN type? There might be some broken code around
>> monitoring if we simply replace the type without implicit casts.
>
> Given the limited usage, how bad would it really be if we simply
> made all those take/return the LSN type?  As long as the type's
> I/O representation looks like the old text format, I suspect
> most queries wouldn't notice.
Are there some plans to awaken this patch (including changing the
output of the functions of xlogfuncs.c)? This would be useful for the
differential backup features I am looking at these days. I imagine
that it is too late for 9.4 though...
Regards,
-- 
Michael