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. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
