Greetings,
* Michael Paquier (michael@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