| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sfrost(at)snowman(dot)net, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Fetching timeline during recovery |
| Date: | 2019-12-23 03:36:56 |
| Message-ID: | 20191223033656.GD34339@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 20, 2019 at 11:14:28AM +0100, Jehan-Guillaume de Rorthais wrote:
> Yes, that would be great but sadly, it would introduce a regression on various
> tools relying on them. At least, the one doing "select *" or most
> probably "select func()".
>
> But anyway, adding 5 funcs is not a big deal neither. Too bad they are so close
> to existing ones though.
Consistency of the data matters a lot if we want to build reliable
tools on top of them in case someone would like to compare the various
modes, and using different functions for those fields creates locking
issues (somewhat the point of Fujii-san upthread?). If nobody likes
the approach of one function, returning one row, taking in input the
mode wanted, then I would not really object Stephen's idea on the
matter about having a multi-column function returning one row.
issues
>> Right. It is a restriction of polymorphic functions. It is in the same
>> relation with pg_stop_backup() and pg_stop_backup(true).
(pg_current_wal_lsn & co talk about LSNs, not TLIs).
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-12-23 03:45:00 | Re: Proposal: Add more compile-time asserts to expose inconsistencies. |
| Previous Message | Michael Paquier | 2019-12-23 02:35:50 | Re: TCP option assign hook doesn't work well if option not supported |