On Tue, Jan 5, 2016 at 7:49 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
> On Sat, Dec 19, 2015 at 12:54 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier
>>> <michael.paquier@gmail.com> wrote:
>>>> On Tue, Dec 15, 2015 at 5:27 AM, Gurjeet Singh wrote:
>>>>> The function, maybe. But emitting an all-nulls row from a view seems
>>>>> counter-intuitive, at least when looking at it in context of relational
>>>>> database.
>>>>
>>>> OK, noted. Any other opinions?
>>>
>>> I wouldn't bother with the view. If we're going to do it, I'd say
>>> just provide the function and let people SELECT * from it if they want
>>> to.
>>
>> OK, I took some time to write a patch for that as attached, added in
>> the next CF here:
>> https://commitfest.postgresql.org/8/447/
>> I am fine switching to an SRF depending on other opinions of people
>> here, it just seems like an overkill knowing the uniqueness of the WAL
>> sender in a server.
>>
>> I have finished with a function and a system view, this came up more
>> in line with the existing things like pg_stat_archiver, and this makes
>> as well the documentation clearer, at least that was my feeling when
>> hacking that.
>
> I also feel showing NULL values may not be good, when there is
> no walreceiver. Instead of SRF function to avoid showing NULL vallues
> how about adding "WHERE s.pid IS NOT NULL" to the system view.
> pid value cannot be NULL, until unless there is no walreceiver.
Yeah, I would not mind switching it to that. A couple of other stat
catalog views do it as well.
--
Michael
