Re: Showing parallel status in \df+

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Showing parallel status in \df+
Дата
Msg-id 20160712132225.GW4028@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Showing parallel status in \df+  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Showing parallel status in \df+  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
> > <alvherre@2ndquadrant.com> wrote:
> >> So prosrc for internal/C and NULL for others?  WFM.
>
> > And so we'd remove "Language" at the same time? That does not sound bad to me.
>
> Hm, I wasn't thinking of that step.  The main knock on "Source code" is
> that it is usually too large to fit into the display grid --- but that
> argument doesn't work against "Language".  Also, while "Language" is
> certainly an implementation detail in some sense, it is a pretty useful
> detail: it gives you a good hint about the likely speed of the function,
> for instance.

Agreed.  I don't have any issue with "Language", really, but I agree
that "Source code" makes the output pretty ridiculous.  I also liked the
idea of changing the name to "internal name" or something along those
lines, rather than having it be "source code", if we keep the column for
C/internal functions.  Keeping is as "source code" wouldn't be accurate.

Thanks!

Stephen

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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Oddity in handling of cached plans for FDW queries
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO