Re: Showing parallel status in \df+

Поиск
Список
Период
Сортировка
От Rushabh Lathia
Тема Re: Showing parallel status in \df+
Дата
Msg-id CAGPqQf00Yx3Pk97XfgPH7wJU6y8XmZz_PU6mUr9utr3WNqFkmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Showing parallel status in \df+  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Showing parallel status in \df+  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost <sfrost@snowman.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@snowman.net> wrote:
* Tom Lane (tgl@sss.pgh.pa.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fix checkpoint skip logic on idle systems by tracking LSN progress
Следующее
От: Emre Hasegeli
Дата:
Сообщение: Re: Floating point comparison inconsistencies of the geometric types