From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Masao Fujii <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: Showing parallel status in \df+ |
Date: | 2016-09-26 19:06:18 |
Message-ID: | 20160926190618.GH5148@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I agree that "do nothing" isn't a good option. I'm not terribly
> > thrilled with just putting the source code at the bottom of the \df+
> > output either, though it's at least slightly less ridiculous than trying
> > to put the source code into a column in a table.
>
> Several people have spoken against that option,
I feel like we're getting wrapped around the axle as it regards who is
perceived to be voting for what.
Based on my review of this thread, we seem to have one person (Peter)
who dislikes removing prosrc from \df+, though he caveated his comments
with being concerned that it was happening after beta2 (which is no
longer the case, of course), see:
f16571cc-bf6f-53a1-6809-f09f48f0a832(at)2ndquadrant(dot)com(dot) Subsequently, in
5aacd611-94b7-3b98-de8e-cae34e18cbee(at)2ndquadrant(dot)com, he seems to
suggest that he might support it if \sf was changed to support wildcards
and multiple results.
Michael had voiced concern that removing prosrc from \df+ would make
debugging more difficult, but subsequent discussion indicated that he
agreed with removing prosrc for non-internal/C functions (which was
later described as 'Internal name'), see:
CAB7nPqTiKT-e7e5cx6WM89m9FR0-Za+BKB1k4_xVFgpcR7drQg(at)mail(dot)gmail(dot)com
Rushabh Lathia had an issue with keeping 'source code' for internal/C
language functions, but not for other languages, see:
CAGPqQf2JZ3Q+bVkXRaQXE+ZtuzHrAYfKP+sYC74Nc+FU5Pnigw(at)mail(dot)gmail(dot)com
Pavel didn't feel having the footer be used for the source code was
appropriate, see:
CAFj8pRBH-m7CmEz2jt49fKGH8qWFgLxxBzfDBBi3GtybbxDDzA(at)mail(dot)gmail(dot)com
I don't particularly care for it either, primairly because \sf could be
improved upon, as suggested by Peter, to avoid the need to have the same
information displayed by both \df+ and \sf.
> but I think it's
> actually pretty clearly an improvement over the status quo. If you
> don't want to see all of that output, fine; look at the first
> screenful and then quit your pager (which probably means "press q").
I agree that it's an improvment over the current \df+ output, but I'm
not convinced that it's better than improving \sf to do that and then
removing prosrc from \df+ and adding 'Internal name' and I'm not sure
that there are actual dissenting votes for that as the end-goal.
Peter's comments seem to be brought up as rejecting the removal of
prosrc from \df+, full-stop, but that's not how I read his actual
comments on this thread.
> If you do want to see all of the output, you'll appreciate not having
> it indented by 60 or 80 columns any more. There's really no
> circumstanced under which it's worse than what we're doing today.
That doesn't mean, at least to me, that we should forgo considering
better alternatives.
> It's fairly likely that there's no option here that will please
> everyone completely, but that's not a reason to reject a patch that is
> clearly better than what we've got now.
We often reject patches which only improve a bit on the status quo
because we wish for a better overall solution, particularly when we're
talking about user interfaces that we don't want to change between every
release.
That's part of the reason that we have a role system today; Tom,
correctly, pointed out that we don't just want a system where a given
object can have multiple owners (one of my first proposals to the lists)
but wished to have role based access controls, which would provide
that capability and more.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-09-26 19:20:00 | Re: proposal: psql \setfileref |
Previous Message | Tom Lane | 2016-09-26 18:54:51 | Re: Allowing GIN array_ops to work on anyarray |