On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
