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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
