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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: should we add a XLogRecPtr/LSN SQL type?
Дата
Msg-id 20131212172000.GB25303@alap2.anarazel.de
обсуждение исходный текст
Ответ на Re: should we add a XLogRecPtr/LSN SQL type?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: should we add a XLogRecPtr/LSN SQL type?
Список pgsql-hackers
Hi,

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. But
just leaving all those as-is seems quite unattractive.

Greetings,

Andres Freund

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Changeset Extraction Interfaces
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Time-Delayed Standbys