Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Wed, Dec 11, 2019 at 10:16:29AM -0500, Stephen Frost wrote: > > I've not followed this discussion very closely but I agree entirely that > > it's really nice to have the timeline be able to be queried in a more > > timely manner than asking through pg_control_checkpoint() gives you. > > > > I'm not sure about adding a text argument to such a function though, I > > would think you'd either have multiple rows if it's an SRF that gives > > you the information on each row and allows a user to filter with a WHERE > > clause, or do something like what pg_stat_replication has and just have > > a bunch of columns. > > With a NULL added for the values which cannot be defined then, like > trying to use the function on a primary for the fields which can only > show up at recovery?
Sure, the function would only return those values that make sense for the state that the system is in. > That would be possible, still my heart tells me > that a function returning one row is a more natural approach for > this stuff. I may be under too much used to what we have in the TAP > tests though. I'm confused- wouldn't the above approach be a function that's returning only one row, if you had a bunch of columns and then had NULL values for those cases that didn't apply..? Or, if you were thinking about the SRF approach that you suggested, you could use a WHERE clause to make it only one row... Though I can see how it's nicer to just have one row in some cases which is why I was suggesting the "bunch of columns" approach. Thanks, Stephen
signature.asc
Description: PGP signature
