On Tue, Jan 5, 2016 at 7:49 PM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > On Sat, Dec 19, 2015 at 12:54 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier >>> <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
