On Wed, Dec 11, 2019 at 10:45:25AM -0500, Stephen Frost wrote:
> 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.
Oh, sorry. I see the confusion now and that's my fault. In
https://www.postgresql.org/message-id/20191211052002.GK72921@paquier.xyz
I mentioned a SRF function which takes an input argument, but that
makes no sense. What I would prefer having is just having one
function, returning one row (LSN, TLI), using in input one argument to
extract the WAL information the caller wants with five possible cases
(write, insert, flush, receive, replay).
Then, what you are referring to is one function which returns all
(LSN,TLI) for the five cases (write, insert, etc.), so it would return
one row with 10 columns, with NULL mapping to the values which have no
meaning (like replay on a primary).
And on top of that we have a third possibility: one SRF function
returning 5 rows with three attributes (mode, LSN, TLI), where mode
corresponds to one value in the set {write, insert, etc.}.
I actually prefer the first one, and you mentioned the second. But
there could be a point in doing the third one. An advantage of the
second and third ones is that you may be able to get a consistent view
of all the data, but it means holding locks to look at the values a
bit longer. Let's see what others think.
--
Michael