Re: Showing parallel status in \df+

From: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(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-28 07:57:11
Message-ID: CAGPqQf00Yx3Pk97XfgPH7wJU6y8XmZz_PU6mUr9utr3WNqFkmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I feel like we're getting wrapped around the axle as it regards who is
> perceived to be voting for what.

Thanks Stephen Frost for listing down all the concerns from the people
on the different approaches.

On Tue, Sep 27, 2016 at 7:56 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > I think the debate is more about whether moving the source display
> > functionality over to \sf is a better solution than rearranging \df+
> > output. (If we had consensus to do that, I'd be happy to go code it,
> > but I'm not going to invest the effort when it seems like we don't.)
>
> Right, that's the main question.
>
> > If we'd had \sf all along, I think it's likely that we would never
> > have put source-code display into \df. But of course we didn't,
>
> Indeed.
>
> > and what would have been best in a green field is not necessarily
> > what's best or achievable given existing reality. Both Robert and
> > Peter have put forward the argument that people are used to finding
> > this info in \df+ output, and I think that deserves a whole lot of
> > weight. The \sf solution might be cleaner, but it's not so much
> > better that it can justify forcing people to relearn their habits.
> >
> > So I think that rearranging \df+ output is really what we ought to
> > be doing here.
>
> Alright, given that Robert's made it clear what his preference is and
> you're in agreement with that, I'll remove my objection to moving down
> that path. I agree that it's better than the current situation. If we
> do end up improving \sf (which seems like a good idea, in general), then
> we may wish to consider a display option to control if the source is
> included in \df+ or not, but that doesn't need to bar this patch from
> going in.
>
> The earlier comments on the thread hadn't been as clear with regard to
> who held what opinions regarding the options and I'm glad that we were
> able to reach a point where it was much clearer that there was strong
> support for keeping the source in \df+.
>
> > I'm not necessarily wedded to any of the precise details of what I did
> > in my patch --- for instance, maybe function bodies ought to be indented
> > one tab stop? But we've not gotten to the merits of such points, for
> > lack of agreement about whether this is the basic approach to take.
>
> As for this, I wouldn't indent or change the source at all. For
> starters, indentation actually matters for some PLs, and I can certainly
> see people wanting to be able to copy/paste from the output, now that
> it'll be possible to reasonably do from the \df+ output.
>

Yes, it seems like "source code" as part of \df+ output (irrespective of
language) is still very much useful for the people - it make sense
not to change it at all. Also agree with Stephen view that once we do
end up improving \sf - we may be re-consider removing source code
from the \df+ output. For now we should stick with the goal for a thread
that started out being about showing parallel status in \df+ output.

> Thanks!
>
> Stephen
>

--
Rushabh Lathia
www.EnterpriseDB.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Emre Hasegeli 2016-09-28 07:59:11 Re: Floating point comparison inconsistencies of the geometric types
Previous Message Michael Paquier 2016-09-28 07:35:52 Re: Fix checkpoint skip logic on idle systems by tracking LSN progress