Re: Remove source code display from \df+?

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Remove source code display from \df+?
Дата
Msg-id CABUevEwDYJK17rVagSimX_E0SSUXxEGFFi4uCp4xTXEVc41DTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Remove source code display from \df+?  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Remove source code display from \df+?  (Isaac Morland <isaac.morland@gmail.com>)
Список pgsql-hackers


On Thu, Jan 12, 2023 at 6:23 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:


st 11. 1. 2023 v 22:11 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> st 11. 1. 2023 v 19:31 odesílatel Magnus Hagander <magnus@hagander.net>
> napsal:
>> This is only about Internal and C, isn't it? Isn't the oid of these
>> static, and identified by INTERNALlanguageId and ClanguageId respectively?
>> So we could just have the query show the prosrc column if the language oid
>> is one of those two, and otherwise show "Please use \sf to view the
>> source"?

> I think it can be acceptable - maybe we can rename the column "source code"
> like "internal name" or some like that.

Yeah, "source code" has always been kind of a misnomer for these
languages.

> again I don't think printing  "Please use \sf to view the source"? " often
> can be user friendly.  \? is clear and \sf is easy to use

We could shorten it to "See \sf" or something like that.  But if we change
the column header to "internal name" or the like, then the column just
obviously doesn't apply for non-internal languages, so leaving it null
should be fine.

+1


Sure, that works for me as well. I agree the suggested text was way too long, I was more thinking of "something in this direction" rather than that exact text. But yes, with a change of names, we can leave it NULL as well. 

--

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: on placeholder entries in view rule action query's range table
Следующее
От: David Christensen
Дата:
Сообщение: Re: Improving btree performance through specializing by key shape, take 2