Re: A patch for get origin from commit_ts.
Michael Paquier <michael@paquier.xyz>
From: michael@paquier.xyz
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Madan Kumar <madankumar1993@gmail.com>, "movead.li@highgo.ca" <movead.li@highgo.ca>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, craig@2ndquadrant.com, petr@2ndquadrant.com, andres@anarazel.de, soumyadeep2007@gmail.com, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2020-07-02T01:50:46Z
Lists: pgsql-hackers
On Tue, Jun 30, 2020 at 02:32:47PM -0400, Alvaro Herrera wrote: > On 2020-Jun-30, Michael Paquier wrote: >> Another question that has popped up when doing this review is what >> would be the use-case of adding this information at SQL level knowing >> that logical replication exists since 10? > > Logical replication in core is a far cry from a fully featured > replication solution. Kindly do not claim that we can now remove > features just because in-core logical replication does not use them; > this argument is ignoring the fact that we're still a long way from > developing actually powerful logical replication capabilities. Thanks for the feedback. If that sounded aggressive in some way, this was not my intention, so my apologies for that. Now, I have to admit that I am worried to see in core code that stands as dead without any actual way to test it directly. Somebody hacking this code cannot be sure if they are breaking it or not, except if they test it with pglogical. So it is good to close the gap here. It also brings a second point IMO, could the documentation be improved to describe more use-cases where these functions would be useful? The documentation gap is not a problem this patch has to deal with, though. -- Michael
Commits
-
Include replication origins in SQL functions for commit timestamp
- b1e48bbe64a4 14.0 landed
-
Create a script that can renumber manually-assigned OIDs.
- a6417078c414 12.0 cited