Thread: Showing parallel status in \df+

Hi all,

Fujii-san has reminded me of the fact that we do not show in \df+ the
parallel status of a function. The output of \df+ is already very
large, so I guess that any people mentally sane already use it with
the expanded display mode, and it may not matter adding more
information.
Thoughts about adding this piece of information?
-- 
Michael

Hi all,

Fujii-san has reminded me of the fact that we do not show in \df+ the
parallel status of a function. The output of \df+ is already very
large, so I guess that any people mentally sane already use it with
the expanded display mode, and it may not matter adding more
information.
Thoughts about adding this piece of information?

On Fri, Jul 8, 2016 at 4:04 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Friday, July 8, 2016, Michael Paquier <michael.paquier@gmail.com> wrote:
>>
>> Hi all,
>>
>> Fujii-san has reminded me of the fact that we do not show in \df+ the
>> parallel status of a function. The output of \df+ is already very
>> large, so I guess that any people mentally sane already use it with
>> the expanded display mode, and it may not matter adding more
>> information.
>> Thoughts about adding this piece of information?
>>
>
> Seems like a good idea to me. It's going to be useful in debugging

Okay. Here we go. I named the column for the parallel information "Parallelism".
--
Michael

On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Fri, Jul 8, 2016 at 4:04 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Friday, July 8, 2016, Michael Paquier <michael.paquier@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Fujii-san has reminded me of the fact that we do not show in \df+ the
>>> parallel status of a function. The output of \df+ is already very
>>> large, so I guess that any people mentally sane already use it with
>>> the expanded display mode, and it may not matter adding more
>>> information.
>>> Thoughts about adding this piece of information?
>>>
>>
>> Seems like a good idea to me. It's going to be useful in debugging
>
> Okay. Here we go. I named the column for the parallel information "Parallelism".
>

Another option could be to name it as Parallel Mode.  We are using
that in the description of "Parallel" in "Create Function"
documentation.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Magnus Hagander <magnus@hagander.net> writes:
> On Friday, July 8, 2016, Michael Paquier <michael.paquier@gmail.com> wrote:
>> Fujii-san has reminded me of the fact that we do not show in \df+ the
>> parallel status of a function. The output of \df+ is already very
>> large, so I guess that any people mentally sane already use it with
>> the expanded display mode, and it may not matter adding more
>> information.
>> Thoughts about adding this piece of information?

> Seems like a good idea to me. It's going to be useful in debugging

If we're going to change \df+ at all, could I lobby for putting the Owner
column next to Security?  They're logically related, and not related to
Volatility which somehow got crammed between.  So I'm imagining the column
order as

Schema   | Name | Result data type | Argument data types |  Type  | Security | Owner | Volatility | Parallel | Language
|Source code | Description 
 

Or maybe Owner then Security.
        regards, tom lane

Amit Kapila <amit.kapila16@gmail.com> writes:
> On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> Okay. Here we go. I named the column for the parallel information "Parallelism".

> Another option could be to name it as Parallel Mode.

I'd go with just "Parallel", to keep it from being noticeably wider than
any of the possible column contents.  Just because you're arguing that
\df+ output is already unreadable in non-expanded mode doesn't mean it's
a good idea to throw away horizontal space for nothing.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > On Friday, July 8, 2016, Michael Paquier <michael.paquier@gmail.com> wrote:
> >> Fujii-san has reminded me of the fact that we do not show in \df+ the
> >> parallel status of a function. The output of \df+ is already very
> >> large, so I guess that any people mentally sane already use it with
> >> the expanded display mode, and it may not matter adding more
> >> information.
> >> Thoughts about adding this piece of information?
>
> > Seems like a good idea to me. It's going to be useful in debugging
>
> If we're going to change \df+ at all, could I lobby for putting the Owner
> column next to Security?  They're logically related, and not related to
> Volatility which somehow got crammed between.  So I'm imagining the column
> order as
>
> Schema   | Name | Result data type | Argument data types |  Type  | Security | Owner | Volatility | Parallel |
Language| Source code | Description  
>
> Or maybe Owner then Security.

I've always wondered why there isn't any way to see the ACL for the
function through \d commands.  I'd suggest including that in \df+ also.
Note that \dn+, \dL+ and \db+, for example, include access privs for
those object types.

Thanks!

Stephen

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
> > <michael.paquier@gmail.com> wrote:
> >> Okay. Here we go. I named the column for the parallel information "Parallelism".
>
> > Another option could be to name it as Parallel Mode.
>
> I'd go with just "Parallel", to keep it from being noticeably wider than
> any of the possible column contents.  Just because you're arguing that
> \df+ output is already unreadable in non-expanded mode doesn't mean it's
> a good idea to throw away horizontal space for nothing.

Agreed.

Thanks!

Stephen

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > On Friday, July 8, 2016, Michael Paquier <michael.paquier@gmail.com> wrote:
> >> Fujii-san has reminded me of the fact that we do not show in \df+ the
> >> parallel status of a function. The output of \df+ is already very
> >> large, so I guess that any people mentally sane already use it with
> >> the expanded display mode, and it may not matter adding more
> >> information.
> >> Thoughts about adding this piece of information?
> 
> > Seems like a good idea to me. It's going to be useful in debugging
> 
> If we're going to change \df+ at all, could I lobby for putting the Owner
> column next to Security?  They're logically related, and not related to
> Volatility which somehow got crammed between.  So I'm imagining the column
> order as
> 
> Schema   | Name | Result data type | Argument data types |  Type  | Security | Owner | Volatility | Parallel |
Language| Source code | Description 
 
> 
> Or maybe Owner then Security.

Agreed.

As a separate concern, IMO having the source code in a \df+ column is
almost completely useless.  I propose to split that out to a separate
\df command (say \df% or \df/) that shows *only* the source code.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> As a separate concern, IMO having the source code in a \df+ column is
> almost completely useless.

Good point.  It works okay for C/internal functions, but in those cases
it's usually redundant with the proname.  For PL functions it's a disaster
formatting-wise, because they're often wide and/or multi-line.

> I propose to split that out to a separate
> \df command (say \df% or \df/) that shows *only* the source code.

As to those names, ick.  Also, what do you envision the output looking
like when multiple functions are selected?  Or would you ban wildcards?
If you do, it's not clear what this does that \sf doesn't do better.

Maybe, given the existence of \sf, we should just drop prosrc from \df+
altogether.
        regards, tom lane

On Sat, Jul 9, 2016 at 4:02 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
> 2016-07-08 20:39 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
>>
>> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> > As a separate concern, IMO having the source code in a \df+ column is
>> > almost completely useless.
>>
>> Good point.  It works okay for C/internal functions, but in those cases
>> it's usually redundant with the proname.  For PL functions it's a disaster
>> formatting-wise, because they're often wide and/or multi-line.
>>
>> > I propose to split that out to a separate
>> > \df command (say \df% or \df/) that shows *only* the source code.
>>
>> As to those names, ick.  Also, what do you envision the output looking
>> like when multiple functions are selected?  Or would you ban wildcards?
>> If you do, it's not clear what this does that \sf doesn't do better.
>>
>> Maybe, given the existence of \sf, we should just drop prosrc from \df+
>> altogether.
>
> prosrc has still benefit for me (for C hacking). Can we show data there only
> for internal or C functions? I agree, it useless for PLpgSQL.

So to sum up:
- Add "Parallel" column
- Add ACLs
- Reordering the columns, I'd suggest as follows):
-- Schema
-- Name
-- Result data type
-- Argument data types
-- Type
-- Language
-- Volatility
-- Parallel
-- Owner
-- Security
-- ACL
-- Source code
-- Description
Or by thema, 1) General info, 2) specificity (volatility, parallel,
type), 3) Ownership.
And regarding "source code", I think that's useful for debugging.
-- 
Michael

On Sat, Jul 9, 2016 at 8:12 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> So to sum up:
> - Add "Parallel" column
> - Add ACLs
> - Reordering the columns, I'd suggest as follows):
> -- Schema
> -- Name
> -- Result data type
> -- Argument data types
> -- Type
> -- Language
> -- Volatility
> -- Parallel
> -- Owner
> -- Security
> -- ACL
> -- Source code
> -- Description
> Or by thema, 1) General info, 2) specificity (volatility, parallel,
> type), 3) Ownership.
> And regarding "source code", I think that's useful for debugging.

Giving the attached, including doc clarifications and column
reshuffling with translatable state set up as well.
--
Michael

Michael Paquier <michael.paquier@gmail.com> writes:
>> - Reordering the columns, I'd suggest as follows):
>> -- Schema
>> -- Name
>> -- Result data type
>> -- Argument data types
>> -- Type
>> -- Language
>> -- Volatility
>> -- Parallel
>> -- Owner
>> -- Security
>> -- ACL
>> -- Source code
>> -- Description

If we're keeping the "Source code" column, I'd be inclined to keep
"Language" adjacent to that.  When thinking of a function as a black
box, both language and source code are implementation details; but
all the other properties listed here are of interest anyway.

(Of course, if we were to get rid of "Source code", the point
would be moot ...)
        regards, tom lane

On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If we're keeping the "Source code" column, I'd be inclined to keep
> "Language" adjacent to that.  When thinking of a function as a black
> box, both language and source code are implementation details; but
> all the other properties listed here are of interest anyway.

OK, no objections to that. And this gives the attached.

> (Of course, if we were to get rid of "Source code", the point
> would be moot ...)

I still think that having source code is useful for debugging, so I
left it out. Note for the committer who will perhaps pick up this
patch: I left out "Source Code", but feel free to remove it if you
think the contrary. It is easier to remove code than adding it back.
--
Michael

Michael Paquier <michael.paquier@gmail.com> writes:
> On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (Of course, if we were to get rid of "Source code", the point
>> would be moot ...)

> I still think that having source code is useful for debugging, so I
> left it out. Note for the committer who will perhaps pick up this
> patch: I left out "Source Code", but feel free to remove it if you
> think the contrary. It is easier to remove code than adding it back.

I still think removing it would make \df+ output substantially more
readable whenever any PLs are involved.  I'm tempted to propose adding
something like \df++ to include the source code for those who really
want that.

However, by my count the vote is two in favor of removing it versus two
against, which is certainly not any kind of consensus, so nothing is going
to happen on that front right away.  Meanwhile, we definitely need to get
the "Parallel" column into 9.6, so I'll review and push the rest of the
changes.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> (Of course, if we were to get rid of "Source code", the point
> >> would be moot ...)
>
> > I still think that having source code is useful for debugging, so I
> > left it out. Note for the committer who will perhaps pick up this
> > patch: I left out "Source Code", but feel free to remove it if you
> > think the contrary. It is easier to remove code than adding it back.
>
> I still think removing it would make \df+ output substantially more
> readable whenever any PLs are involved.  I'm tempted to propose adding
> something like \df++ to include the source code for those who really
> want that.
>
> However, by my count the vote is two in favor of removing it versus two
> against, which is certainly not any kind of consensus, so nothing is going
> to happen on that front right away.  Meanwhile, we definitely need to get
> the "Parallel" column into 9.6, so I'll review and push the rest of the
> changes.

I agree with removing the source code field, though I did like the
suggestion mentioned elsewhere for having it shown when it's just a C
symbol but not otherwise.  If we can find a way to have the C symbol
shown when it's a C or internal function, I'm fine with that, but the
source code field having entier pl/sql and pl/pgsql functions in it
doesn't work and \sf should be used instead.

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:
> I agree with removing the source code field, though I did like the
> suggestion mentioned elsewhere for having it shown when it's just a C
> symbol but not otherwise.  If we can find a way to have the C symbol
> shown when it's a C or internal function, I'm fine with that, but the
> source code field having entier pl/sql and pl/pgsql functions in it
> doesn't work and \sf should be used instead.

It would certainly be easy enough to do that, as long as you don't mind
hard-wiring into psql the knowledge that "internal" and "C" are the
languages to show prosrc for.  "Source code" would no longer be a very
appropriate column name, though it already was not for these cases.
I'd be inclined to call it "Internal name" instead.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I agree with removing the source code field, though I did like the
> > suggestion mentioned elsewhere for having it shown when it's just a C
> > symbol but not otherwise.  If we can find a way to have the C symbol
> > shown when it's a C or internal function, I'm fine with that, but the
> > source code field having entier pl/sql and pl/pgsql functions in it
> > doesn't work and \sf should be used instead.
>
> It would certainly be easy enough to do that, as long as you don't mind
> hard-wiring into psql the knowledge that "internal" and "C" are the
> languages to show prosrc for.  "Source code" would no longer be a very
> appropriate column name, though it already was not for these cases.
> I'd be inclined to call it "Internal name" instead.

That would certainly work for me.

Thanks!

Stephen

Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:

> > It would certainly be easy enough to do that, as long as you don't mind
> > hard-wiring into psql the knowledge that "internal" and "C" are the
> > languages to show prosrc for.  "Source code" would no longer be a very
> > appropriate column name, though it already was not for these cases.
> > I'd be inclined to call it "Internal name" instead.
> 
> That would certainly work for me.

So prosrc for internal/C and NULL for others?  WFM.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Stephen Frost wrote:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>
>> > It would certainly be easy enough to do that, as long as you don't mind
>> > hard-wiring into psql the knowledge that "internal" and "C" are the
>> > languages to show prosrc for.  "Source code" would no longer be a very
>> > appropriate column name, though it already was not for these cases.
>> > I'd be inclined to call it "Internal name" instead.
>>
>> That would certainly work for me.
>
> 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.
-- 
Michael

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.
        regards, tom lane

* 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

Stephen Frost <sfrost@snowman.net> writes:
> 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.

It's sounding to me like we have consensus on this proposal to further
change \df+ to replace the "Source code" column with "Internal name",
which is prosrc for C and internal-language functions but NULL otherwise.

If I've not heard objections by tomorrow I'll go make that change.

Are we satisfied with telling people to use \sf to see the source code
for a PL function?  Or should there be another variant of \df that
still provides source code?
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > 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.
>
> It's sounding to me like we have consensus on this proposal to further
> change \df+ to replace the "Source code" column with "Internal name",
> which is prosrc for C and internal-language functions but NULL otherwise.
>
> If I've not heard objections by tomorrow I'll go make that change.
>
> Are we satisfied with telling people to use \sf to see the source code
> for a PL function?  Or should there be another variant of \df that
> still provides source code?

I don't see the point in having a \df variant be the same as what \sf
is.  I could possibly see extending \sf in some way, if there are things
that it doesn't currently do that \df does (and those things are
useful).

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Are we satisfied with telling people to use \sf to see the source code
>> for a PL function?  Or should there be another variant of \df that
>> still provides source code?

> I don't see the point in having a \df variant be the same as what \sf
> is.  I could possibly see extending \sf in some way, if there are things
> that it doesn't currently do that \df does (and those things are
> useful).

I certainly agree that \sf already does what it does just fine.  The
question is more about whether anyone is likely to think that removing
source code from \df+ output constitutes an important loss of
functionality.

I had some vague ideas about inventing a new \df behavior modeled on
the way that \d+ shows view definitions, that is, put the function body
in a footer rather than in the tabular output proper.  So you could
imagine something like

# \df++ foo*Schema | Name | ...
--------+------+-...public | fooa | ...public | foob | ...
Source code for fooa(int, text): ... body of fooa ...
Source code for foob(text, text, numeric): ... body of foob ...

But I'm not sure it's worth the trouble.  And anyway we could add this
later.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Are we satisfied with telling people to use \sf to see the source code
> >> for a PL function?  Or should there be another variant of \df that
> >> still provides source code?
>
> > I don't see the point in having a \df variant be the same as what \sf
> > is.  I could possibly see extending \sf in some way, if there are things
> > that it doesn't currently do that \df does (and those things are
> > useful).
>
> I certainly agree that \sf already does what it does just fine.  The
> question is more about whether anyone is likely to think that removing
> source code from \df+ output constitutes an important loss of
> functionality.

Right, I understood that to be your question and was intending to answer
it with "no."

> I had some vague ideas about inventing a new \df behavior modeled on
> the way that \d+ shows view definitions, that is, put the function body
> in a footer rather than in the tabular output proper.  So you could
> imagine something like
>
> # \df++ foo*
>  Schema | Name | ...
> --------+------+-...
>  public | fooa | ...
>  public | foob | ...
> Source code for fooa(int, text):
>   ... body of fooa ...
> Source code for foob(text, text, numeric):
>   ... body of foob ...
>
> But I'm not sure it's worth the trouble.  And anyway we could add this
> later.

Agreed on both counts.

Thanks!

Stephen

On 7/12/16 12:17 PM, Tom Lane wrote:
> It's sounding to me like we have consensus on this proposal to further
> change \df+ to replace the "Source code" column with "Internal name",
> which is prosrc for C and internal-language functions but NULL otherwise.
> 
> If I've not heard objections by tomorrow I'll go make that change.
> 
> Are we satisfied with telling people to use \sf to see the source code
> for a PL function?  Or should there be another variant of \df that
> still provides source code?

I'm quite fond of having the full source code show in \df+ and I'm
against removing it on short notice past beta2, discussed under a
"false" subject heading.

This is long-standing, intentional behavior, not a regression, and
changing it should get wider consultation.  Please submit a patch to the
next commit fest instead.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut wrote:

> I'm quite fond of having the full source code show in \df+ and I'm
> against removing it on short notice past beta2, discussed under a
> "false" subject heading.

How do you use it?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 7/12/16 12:17 PM, Tom Lane wrote:
> > It's sounding to me like we have consensus on this proposal to further
> > change \df+ to replace the "Source code" column with "Internal name",
> > which is prosrc for C and internal-language functions but NULL otherwise.
> >
> > If I've not heard objections by tomorrow I'll go make that change.
> >
> > Are we satisfied with telling people to use \sf to see the source code
> > for a PL function?  Or should there be another variant of \df that
> > still provides source code?
>
> I'm quite fond of having the full source code show in \df+ and

I'm curious how it's useful and in what way \sf does not accomplish what
you use \df+ for.  I understand that's a change, but I believe it's a
positive one and would make \df+ much more generally useful.  I tend to
resort to selecting columns out of pg_proc more often than I use \df+,
which is certainly not what we're going for.

> I'm
> against removing it on short notice past beta2

We've already had to change the structure of \df+; I'm not convinced
that avoiding doing so further now, just to do so again in the next
release, is actually a better answer than changing it now.

Thanks!

Stephen

On 7/12/16 7:11 PM, Stephen Frost wrote:
> I'm curious how it's useful and in what way \sf does not accomplish what
> you use \df+ for.

One main use is to see multiple related functions next to each other and
compare their source code.  But also because one is used to \df and
wants to see everything there and not in a different format like \sf.

So ways to consolidate that would be supporting wildcards and multiple
results in \sf, and/or the option to show a truncated version of the
source code in \df+, or perhaps a \df++.

> We've already had to change the structure of \df+; I'm not convinced
> that avoiding doing so further now, just to do so again in the next
> release, is actually a better answer than changing it now.

We added a new column related to a new feature, which is hardly changing
the structure.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
>> I'm curious how it's useful and in what way \sf does not accomplish what
>> you use \df+ for.

> One main use is to see multiple related functions next to each other and
> compare their source code.  But also because one is used to \df and
> wants to see everything there and not in a different format like \sf.

Well, how about my suggestion of moving source code to a footer?
I had just been experimenting to see how painful that would be, and
it doesn't seem awful --- see attached.

            regards, tom lane

diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 27be102..f5dfd83 100644
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*************** describeFunctions(const char *functypes,
*** 294,308 ****
      bool        showNormal = strchr(functypes, 'n') != NULL;
      bool        showTrigger = strchr(functypes, 't') != NULL;
      bool        showWindow = strchr(functypes, 'w') != NULL;
      bool        have_where;
      PQExpBufferData buf;
      PGresult   *res;
      printQueryOpt myopt = pset.popt;
      static const bool translate_columns[] = {false, false, false, false, true, true, true, false, true, false, false,
false,false}; 

-     /* No "Parallel" column before 9.6 */
-     static const bool translate_columns_pre_96[] = {false, false, false, false, true, true, false, true, false,
false,false, false}; 
-
      if (strlen(functypes) != strspn(functypes, "antwS+"))
      {
          psql_error("\\df only takes [antwS+] as options\n");
--- 294,316 ----
      bool        showNormal = strchr(functypes, 'n') != NULL;
      bool        showTrigger = strchr(functypes, 't') != NULL;
      bool        showWindow = strchr(functypes, 'w') != NULL;
+     bool        have_parallel;
      bool        have_where;
      PQExpBufferData buf;
      PGresult   *res;
+     printTableContent cont;
      printQueryOpt myopt = pset.popt;
+     int            nfields,
+                 r,
+                 c;
+     const int    schema_col = 0;
+     const int    proname_col = 1;
+     const int    proargs_col = 3;
+     const int    parallel_col = 6;
+     const int    lanname_col = 10;
+     const int    prosrc_col = 11;
      static const bool translate_columns[] = {false, false, false, false, true, true, true, false, true, false, false,
false,false}; 

      if (strlen(functypes) != strspn(functypes, "antwS+"))
      {
          psql_error("\\df only takes [antwS+] as options\n");
*************** describeFunctions(const char *functypes,
*** 323,328 ****
--- 331,344 ----
              showWindow = true;
      }

+     /*
+      * proparallel only exists in server versions >= 9.6.  Before that, we
+      * retrieve a null "parallel" column so as to keep column numbering
+      * consistent in the query result, and then skip adding that column to the
+      * printed table.
+      */
+     have_parallel = (pset.sversion >= 90600);
+
      initPQExpBuffer(&buf);

      printfPQExpBuffer(&buf,
*************** describeFunctions(const char *functypes,
*** 424,430 ****
                            gettext_noop("stable"),
                            gettext_noop("volatile"),
                            gettext_noop("Volatility"));
!         if (pset.sversion >= 90600)
              appendPQExpBuffer(&buf,
                                ",\n CASE\n"
                                "  WHEN p.proparallel = 'r' THEN '%s'\n"
--- 440,446 ----
                            gettext_noop("stable"),
                            gettext_noop("volatile"),
                            gettext_noop("Volatility"));
!         if (have_parallel)
              appendPQExpBuffer(&buf,
                                ",\n CASE\n"
                                "  WHEN p.proparallel = 'r' THEN '%s'\n"
*************** describeFunctions(const char *functypes,
*** 435,440 ****
--- 451,459 ----
                                gettext_noop("safe"),
                                gettext_noop("unsafe"),
                                gettext_noop("Parallel"));
+         else
+             appendPQExpBufferStr(&buf,
+                                  ",\n NULL as \"Parallel\"");
          appendPQExpBuffer(&buf,
                         ",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\""
                   ",\n CASE WHEN prosecdef THEN '%s' ELSE '%s' END AS \"%s\"",
*************** describeFunctions(const char *functypes,
*** 449,455 ****
                            ",\n p.prosrc as \"%s\""
                  ",\n pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
                            gettext_noop("Language"),
!                           gettext_noop("Source code"),
                            gettext_noop("Description"));
      }

--- 468,474 ----
                            ",\n p.prosrc as \"%s\""
                  ",\n pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
                            gettext_noop("Language"),
!                           gettext_noop("Internal name"),
                            gettext_noop("Description"));
      }

*************** describeFunctions(const char *functypes,
*** 543,569 ****
      appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 4;");

      res = PSQLexec(buf.data);
-     termPQExpBuffer(&buf);
      if (!res)
          return false;

!     myopt.nullPrint = NULL;
!     myopt.title = _("List of functions");
!     myopt.translate_header = true;
!     if (pset.sversion >= 90600)
      {
!         myopt.translate_columns = translate_columns;
!         myopt.n_translate_columns = lengthof(translate_columns);
      }
!     else
      {
!         myopt.translate_columns = translate_columns_pre_96;
!         myopt.n_translate_columns = lengthof(translate_columns_pre_96);
      }

!     printQuery(res, &myopt, pset.queryFout, false, pset.logfile);

      PQclear(res);
      return true;
  }

--- 562,634 ----
      appendPQExpBufferStr(&buf, "ORDER BY 1, 2, 4;");

      res = PSQLexec(buf.data);
      if (!res)
+     {
+         termPQExpBuffer(&buf);
          return false;
+     }

!     nfields = PQnfields(res);
!     Assert(lengthof(translate_columns) >= nfields);
!
!     printTableInit(&cont, &myopt.topt, _("List of functions"),
!                    (have_parallel || !verbose) ? nfields : nfields - 1,
!                    PQntuples(res));
!
!     for (c = 0; c < nfields; c++)
      {
!         if (c == parallel_col && !have_parallel)
!             continue;
!         printTableAddHeader(&cont, PQfname(res, c), true,
!                             column_type_alignment(PQftype(res, c)));
      }
!
!     /* set cells */
!     for (r = 0; r < cont.nrows; r++)
      {
!         for (c = 0; c < nfields; c++)
!         {
!             char       *cell;
!
!             if (c == parallel_col && !have_parallel)
!                 continue;
!
!             if (PQgetisnull(res, r, c))
!                 cell = "";
!             else
!                 cell = PQgetvalue(res, r, c);
!
!             if (c == prosrc_col)
!             {
!                 const char *lanname = PQgetvalue(res, r, lanname_col);
!
!                 if (strcmp(lanname, "internal") == 0 ||
!                     strcmp(lanname, "c") == 0)
!                      /* keep prosrc in the "Internal name" column */ ;
!                 else
!                 {
!                     /* put prosrc in a footer, instead */
!                     printfPQExpBuffer(&buf,
!                                       _("Source code of function %s.%s(%s):"),
!                                       PQgetvalue(res, r, schema_col),
!                                       PQgetvalue(res, r, proname_col),
!                                       PQgetvalue(res, r, proargs_col));
!                     printTableAddFooter(&cont, buf.data);
!                     printTableAddFooter(&cont, cell);
!                     cell = "";
!                 }
!             }
!
!             printTableAddCell(&cont, cell, translate_columns[c], false);
!         }
      }

!     printTable(&cont, pset.queryFout, false, pset.logfile);
!     printTableCleanup(&cont);

      PQclear(res);
+     termPQExpBuffer(&buf);
+
      return true;
  }

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
> > I'm curious how it's useful and in what way \sf does not accomplish what
> > you use \df+ for.
>
> One main use is to see multiple related functions next to each other and
> compare their source code.  But also because one is used to \df and
> wants to see everything there and not in a different format like \sf.

Except that you don't actually get to see related functions next to each
other with \df+, you see them one after each other, which is not a very
useful diff comparison.  I don't see any value in the "because that's
how it's always been" argument.

> So ways to consolidate that would be supporting wildcards and multiple
> results in \sf, and/or the option to show a truncated version of the
> source code in \df+, or perhaps a \df++.

I don't mind adding wildcard support to \sf if there is interest.  I
dislike the "\df++" idea.  I have no idea how a "truncated version"
would ever be anything but noise for non-C/internal functions.

> > We've already had to change the structure of \df+; I'm not convinced
> > that avoiding doing so further now, just to do so again in the next
> > release, is actually a better answer than changing it now.
>
> We added a new column related to a new feature, which is hardly changing
> the structure.

I disagree.  Adding a column is certainly changing the structure, as is
removing one.  This certainly hasn't changed my opinion that it's
worthwhile to consider this change, even at this point in the release
cycle, given we need to make a change regardless.

Thanks!

Stephen

On Jul 13, 2016, at 12:25 PM, Stephen Frost <sfrost@snowman.net> wrote:
> I disagree.  Adding a column is certainly changing the structure, as is
> removing one.  This certainly hasn't changed my opinion that it's
> worthwhile to consider this change, even at this point in the release
> cycle, given we need to make a change regardless.

Without getting into the substantive question here, I think that as a matter of policy, when somebody thinks we're
whackingthings around too much post-beta, we should lean in the direction of whacking them around less.  You don't have
toagree with Peter on the merits to think that this is optional tinkering. It clearly is. 

...Robert

On Mon, Aug 22, 2016 at 4:49 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> This feature shows source code for PL function when \df statement was used.
> I am not too sure, if this functionality is necessary - but I don't see any
> argument against. Sometimes it can be useful, mainly when we work with
> overloaded functions.

Wait, really?  I thought Peter was complaining about the fact that it
*removed* that from the display.

He also complained about the fact that the subject line of this thread
and what the patch actually does have diverged considerably, which I
think is a fair complaint.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 8/22/16 1:52 PM, Pavel Stehule wrote:
> If I understand to purpose of this patch - it is compromise - PL source
> is removed from table, but it is printed in result.

What does it do if you are displaying more than one function?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 8/22/16 1:52 PM, Pavel Stehule wrote:
>> If I understand to purpose of this patch - it is compromise - PL source
>> is removed from table, but it is printed in result.

> What does it do if you are displaying more than one function?

It prints more than one footer.  It's very much like the way that, say,
rules are printed for tables by \d.
        regards, tom lane

I wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> What does it do if you are displaying more than one function?

> It prints more than one footer.  It's very much like the way that, say,
> rules are printed for tables by \d.

Or to be concrete: instead of


regression=# \df+ foo*
     List of functionsSchema |  Name   | Result data type | Argument data types |  Type  | Volatility | Parallel |
Owner  | Security | Access privileges | Language |                            Source code                             |
Description
 

--------+---------+------------------+---------------------+--------+------------+----------+----------+----------+-------------------+----------+--------------------------------------------------------------------+-------------public
|foo1    | integer          | integer             | normal | volatile   | unsafe   | postgres | invoker  |
    | plpgsql  |                                                                   +|        |         |
 |                     |        |            |          |          |          |                   |          | begin
                                                        +|        |         |                  |                     |
     |            |          |          |          |                   |          |   return $1 + 1;
                             +|        |         |                  |                     |        |            |
  |          |          |                   |          | end
  +|        |         |                  |                     |        |            |          |          |          |
                 |          |                                                                    | public | foo2    |
integer         | integer             | normal | volatile   | unsafe   | postgres | invoker  |                   | sql
   |  select $1 + 2                                                     | public | footest | void             |
           | normal | volatile   | unsafe   | postgres | invoker  |                   | plpgsql  |
                                            +|        |         |                  |                     |        |
      |          |          |          |                   |          | -- override the global
                 +|        |         |                  |                     |        |            |          |
 |          |                   |          | #print_strict_params on                                           +|
|         |                  |                     |        |            |          |          |          |
     |          | declare                                                           +|        |         |
  |                     |        |            |          |          |          |                   |          | x
record;                                                        +|        |         |                  |
   |        |            |          |          |          |                   |          | p1 int := 2;
                                    +|        |         |                  |                     |        |
|         |          |          |                   |          | p3 text := 'foo';
          +|        |         |                  |                     |        |            |          |          |
     |                   |          | begin                                                             +|        |
   |                  |                     |        |            |          |          |          |
|         |   -- too many rows                                                +|        |         |                  |
                  |        |            |          |          |          |                   |          |   select *
fromfoo where f1 > p1 or f1::text = p3  into strict x;+|        |         |                  |                     |
   |            |          |          |          |                   |          |   raise notice 'x.f1 = %, x.f2 = %',
x.f1,x.f2;                  +|        |         |                  |                     |        |            |
 |          |          |                   |          | end
  | 
 
(3 rows)


you get


regression=# \df+ foo*                                                                              List of
functionsSchema|  Name   | Result data type | Argument data types |  Type  | Volatility | Parallel |  Owner   |
Security| Access privileges | Language | Internal name | Description 
 

--------+---------+------------------+---------------------+--------+------------+----------+----------+----------+-------------------+----------+---------------+-------------public
|foo1    | integer          | integer             | normal | volatile   | unsafe   | postgres | invoker  |
    | plpgsql  |               | public | foo2    | integer          | integer             | normal | volatile   |
unsafe  | postgres | invoker  |                   | sql      |               | public | footest | void             |
                | normal | volatile   | unsafe   | postgres | invoker  |                   | plpgsql  |               |

Source code of function public.foo1(integer):

begin return $1 + 1;
end

Source code of function public.foo2(integer):select $1 + 2 
Source code of function public.footest():

-- override the global
#print_strict_params on
declare
x record;
p1 int := 2;
p3 text := 'foo';
begin -- too many rows select * from foo where f1 > p1 or f1::text = p3  into strict x; raise notice 'x.f1 = %, x.f2 =
%',x.f1, x.f2;
 
end


C functions are still compact, and they're more sanely labeled too:

regression=# \df+ sin*                                                                               List of functions
Schema  | Name | Result data type | Argument data types |  Type  | Volatility | Parallel |  Owner   | Security | Access
privileges| Language | Internal name |  Description  
 

------------+------+------------------+---------------------+--------+------------+----------+----------+----------+-------------------+----------+---------------+---------------pg_catalog
|sin  | double precision | double precision    | normal | immutable  | safe     | postgres | invoker  |
 | internal | dsin          | sinepg_catalog | sind | double precision | double precision    | normal | immutable  |
safe    | postgres | invoker  |                   | internal | dsind         | sine, degrees
 
(2 rows)


Admittedly, this is not a huge improvement when working in expanded
display mode, but in normal mode I think it's the difference between a
usable display and a useless one.
        regards, tom lane

Pavel Stehule <pavel.stehule@gmail.com> writes:
> Using footer for this purpose is little bit strange. What about following
> design?
> 1. move out source code of PL functions from \df+
> 2. allow not unique filter in \sf and allow to display multiple functions

Wasn't that proposed and rejected upthread?
        regards, tom lane

I wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> Using footer for this purpose is little bit strange. What about following
>> design?
>> 1. move out source code of PL functions from \df+
>> 2. allow not unique filter in \sf and allow to display multiple functions

> Wasn't that proposed and rejected upthread?

So ... why did you put this patch in "Waiting on Author" state?  AFAIK,
we had dropped the idea of relying on \sf for this, mainly because
Peter complained about \df+ no longer providing source code.  I follow
his point: if you're used to using \df+ to see source code, you probably
can figure it out quickly if that command shows the source in a different
place than before.  But if it doesn't show it at all, using \sf instead
might not occur to you right away.
        regards, tom lane

Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> I agree with the argument in this thread, having "Source code" as part
> of \df+ is bit annoying, specifically when output involve some really
> big PL language functions. Having is separate does make \df+ output more
> readable. So I would vote for \df++ rather then adding the source code
> as part of footer for \df+.

If it's unreadable in \df+, how would \df++ make that any better?
        regards, tom lane

Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2016-09-23 7:22 GMT+02:00 Rushabh Lathia <rushabh.lathia@gmail.com>:
>> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> If it's unreadable in \df+, how would \df++ make that any better?

>> Eventhough source code as part of \df+ is bit annoying (specifically
>> for PL functions), I noticed the argument in this thread that it's
>> useful information for some of.  So \df++ is just alternate option for
>> the those who want the source code.

> ++ is little bit obscure. So better to remove src everywhere.

Well, that was suggested upthread (which is where the idea of relying
on \sf came from) and Peter objected on the quite reasonable grounds
that people expect \df+ to provide this info and won't know to go
use \sf instead.  So I'm afraid that suggestion is going nowhere.

I think the options that have a chance of happening are to rearrange
\df+ output more or less as in my patch, or to do nothing.  I'm not very
happy about "do nothing", but that seems to be where we're ending up.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > 2016-09-23 7:22 GMT+02:00 Rushabh Lathia <rushabh.lathia@gmail.com>:
> >> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> If it's unreadable in \df+, how would \df++ make that any better?
>
> >> Eventhough source code as part of \df+ is bit annoying (specifically
> >> for PL functions), I noticed the argument in this thread that it's
> >> useful information for some of.  So \df++ is just alternate option for
> >> the those who want the source code.
>
> > ++ is little bit obscure. So better to remove src everywhere.
>
> Well, that was suggested upthread (which is where the idea of relying
> on \sf came from) and Peter objected on the quite reasonable grounds
> that people expect \df+ to provide this info and won't know to go
> use \sf instead.  So I'm afraid that suggestion is going nowhere.

For my 2c, I disagree that "just because it's always been there and
that's where people know to go look" is a reason to not remove it.

Moving src out of \df+ will mean that people looking for it will need to
use \? to see where it went (or use \ef, which is what I'd argue most
already do today..), but I hardly see that as a huge issue and the
improvement in readability of \df+ is well worth that cost.

> I think the options that have a chance of happening are to rearrange
> \df+ output more or less as in my patch, or to do nothing.  I'm not very
> happy about "do nothing", but that seems to be where we're ending up.

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.

If we really are worried that people who know how to use \df+ and how to
write plpgsql (or other PL) code can't figure out how to view the src
with \sf or \ef, then we could include at the bottom of the \df+ output
a hint which essentially says "use \sf to view function source".

Alternativly, and I kind of hate suggesting this, but it's not like most
people don't already have a .psqlrc to deal with our silly defaults, we
could add a variable to control if src is included in \df+ or not.

Thanks!

Stephen

On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost <sfrost@snowman.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, 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").
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.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost <sfrost@snowman.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@2ndquadrant.com.  Subsequently, in
5aacd611-94b7-3b98-de8e-cae34e18cbee@2ndquadrant.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@mail.gmail.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@mail.gmail.com

Pavel didn't feel having the footer be used for the source code was
appropriate, see:
CAFj8pRBH-m7CmEz2jt49fKGH8qWFgLxxBzfDBBi3GtybbxDDzA@mail.gmail.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

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.

True.  It's not very clear; thanks for trying to shed some light on it.

> 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.

IMHO, we've had \dWHATEVER as the way to find out about things for so
long that we should just stick with it.  I think users are used to
remembering which character they need to stick after \d to get
information on the object type in which they are currently interested;
I know I am.  If we move this all over to \sf people will have trouble
finding it.  I'll get used to it because I "work here" and so will
you, but I think most users will just type \df and then \df+ and then
say ... well where the %@#! did they put it?

>> 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.

I don't think so, either, but if we could agree that "Tom's patch >
doing nothing" then he could commit it and we could debate whether
there's something even better.

> 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.

Sure, that's true.  In this case, however, I believe that the amount
of improvement that's possible is pretty limited.  Super-wide lines
that rapid repeatedly are bad; we can probably all agree on that.
Whether or not it's better to adjust \df+ as Tom has done or introduce
\df++ or enhance \sf or something else entirely is debatable;
different people prefer different things for different reasons - or
for no reason, as some of this is surely down to personal preference.
If I thought Tom's patch solved 20% of the problem while kicking 80%
of it down the road, I'd probably agree that we ought not to adopt it;
but in fact I think it's more like the reverse -- at least in the
narrow sense of keeping \df+ output readable, which I think is about
as ambitious as we should make our goal for a thread that started out
being about showing parallel status in \df+ output.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> That doesn't mean, at least to me, that we should forgo considering
>> better alternatives.

> I don't think so, either, but if we could agree that "Tom's patch >
> doing nothing" then he could commit it and we could debate whether
> there's something even better.

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.)

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,
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.

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.
        regards, tom lane

* 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.

Thanks!

Stephen

Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> 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.

I'm not sure if we've arrived at a consensus or not, but here's my
current thinking: it's very early in the v10 cycle, so we have time
to experiment.  I propose to push my current patch (ie, move PL function
source code to \df+ footers), and we can use it in HEAD for awhile
and see what we think.  We can alway improve or revert it later.
        regards, tom lane

Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2016-09-28 16:03 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> I propose to push my current patch (ie, move PL function
>> source code to \df+ footers), and we can use it in HEAD for awhile
>> and see what we think.  We can alway improve or revert it later.

> I had some objection to format of source code - it should be full source
> code, not just header and body.

That would be redundant with stuff that's in the main part of the \df
display.  I really don't need to see the argument types twice, for instance.
        regards, tom lane

Pavel Stehule wrote:

> I am sorry, I disagree. Proposed form is hard readable. Is not possible to
> simply copy/paste.

Why do you care?  You can use \sf if you want to copy&paste the
function code.

> I cannot to imagine any use case for proposed format.

My vote (which was not counted by Stephen) was to remove it from \df+
altogether.  I stand by that.  People who are used to seeing the output
in \df+ will wonder "where the heck did it go" and eventually figure it
out, at which point it's no longer a problem.  We're not breaking
anyone's scripts, that's for sure.

If we're not removing it, I +0 support the option of moving it to
footers.  I'm -1 on doing nothing.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Pavel Stehule wrote:
> > I cannot to imagine any use case for proposed format.
>
> My vote (which was not counted by Stephen) was to remove it from \df+

Oh, sorry about that, not sure how I missed it. :/

> altogether.  I stand by that.  People who are used to seeing the output
> in \df+ will wonder "where the heck did it go" and eventually figure it
> out, at which point it's no longer a problem.  We're not breaking
> anyone's scripts, that's for sure.
>
> If we're not removing it, I +0 support the option of moving it to
> footers.  I'm -1 on doing nothing.

This is more-or-less the same position that I have.

Thanks!

Stephen

Pavel Stehule <pavel.stehule@gmail.com> writes:
> We are in cycle because prosrc field is used for two independent features -
> and then it can be hard to find a agreement.

I thought pretty much everyone was on board with the idea of keeping
prosrc in \df+ for internal/C-language functions (and then probably
renaming the column, since it isn't actually source code in that case).
The argument is over what to do for PL functions, which is only one use
case not two.
        regards, tom lane

On 9/28/16 2:59 PM, Alvaro Herrera wrote:
>> I am sorry, I disagree. Proposed form is hard readable. Is not possible to
>> > simply copy/paste.
> Why do you care?  You can use \sf if you want to copy&paste the
> function code.
>
>> > I cannot to imagine any use case for proposed format.
> My vote (which was not counted by Stephen) was to remove it from \df+
> altogether.  I stand by that.  People who are used to seeing the output
> in \df+ will wonder "where the heck did it go" and eventually figure it
> out, at which point it's no longer a problem.  We're not breaking
> anyone's scripts, that's for sure.
>
> If we're not removing it, I +0 support the option of moving it to
> footers.  I'm -1 on doing nothing.

I agree with everything Alvaro just said.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 9/28/16 2:59 PM, Alvaro Herrera wrote:
>> My vote (which was not counted by Stephen) was to remove it from \df+
>> altogether.  I stand by that.  People who are used to seeing the output
>> in \df+ will wonder "where the heck did it go" and eventually figure it
>> out, at which point it's no longer a problem.  We're not breaking
>> anyone's scripts, that's for sure.
>> 
>> If we're not removing it, I +0 support the option of moving it to
>> footers.  I'm -1 on doing nothing.

> I agree with everything Alvaro just said.

Well, alternatively, can we get a consensus for doing that?  People
did speak against removing PL source code from \df+ altogether, but
maybe they're willing to reconsider if the alternative is doing nothing.

Personally I'm on the edge of washing my hands of the whole thing...
        regards, tom lane

On Sat, Oct 1, 2016 at 9:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 9/28/16 2:59 PM, Alvaro Herrera wrote:
>>> My vote (which was not counted by Stephen) was to remove it from \df+
>>> altogether.  I stand by that.  People who are used to seeing the output
>>> in \df+ will wonder "where the heck did it go" and eventually figure it
>>> out, at which point it's no longer a problem.  We're not breaking
>>> anyone's scripts, that's for sure.
>>>
>>> If we're not removing it, I +0 support the option of moving it to
>>> footers.  I'm -1 on doing nothing.
>
>> I agree with everything Alvaro just said.
>
> Well, alternatively, can we get a consensus for doing that?  People
> did speak against removing PL source code from \df+ altogether, but
> maybe they're willing to reconsider if the alternative is doing nothing.
>
> Personally I'm on the edge of washing my hands of the whole thing...

Let's remove it and move on then. By looking again at this thread and
particularly https://www.postgresql.org/message-id/20160926190618.GH5148@tamriel.snowman.net
(thanks Stephen for the summary) that's where we are heading to.
-- 
Michael

On Sun, Oct 2, 2016 at 10:55 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Let's remove it and move on then. By looking again at this thread and
> particularly https://www.postgresql.org/message-id/20160926190618.GH5148@tamriel.snowman.net
> (thanks Stephen for the summary) that's where we are heading to.

(Moved to next CF)
-- 
Michael

On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, alternatively, can we get a consensus for doing that?  People
> did speak against removing PL source code from \df+ altogether, but
> maybe they're willing to reconsider if the alternative is doing nothing.
>
> Personally I'm on the edge of washing my hands of the whole thing...

The hand-washing strategy has a lot to recommend it; this thread is
going nowhere fast.  I don't care enough to put up a big stink about
the idea of removing PL source code from \df+ output, but it's not
what I'd choose to do; let's call me -0 on that option.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2016-10-03 21:54 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
>> On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Personally I'm on the edge of washing my hands of the whole thing...

>> The hand-washing strategy has a lot to recommend it; this thread is
>> going nowhere fast.  I don't care enough to put up a big stink about
>> the idea of removing PL source code from \df+ output, but it's not
>> what I'd choose to do; let's call me -0 on that option.

> I can write the patch - I am sure so cleaned \df+ output will be better
> than what we have now.

Writing a patch is not the problem.  Getting consensus on what it should
do is the problem.
        regards, tom lane

On 10/3/16 3:18 PM, Pavel Stehule wrote:
> I am feeling consensus on removing source of PL from \dt+. There is
> partial consensus on saving this field (renamed) for C and internal
> language. I am not sure about consensus about \sf enhancing.

FWIW, I'm completely in favor of ditching PL source code. I'm neutral on 
C and internal.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

All,

Starting a new thread with an accurate name to see if we can't get
somewhere with this topic.

* Pavel Stehule (pavel.stehule@gmail.com) wrote:
> 2016-10-08 23:46 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
> > On 10/3/16 3:18 PM, Pavel Stehule wrote:
> >> I am feeling consensus on removing source of PL from \dt+. There is
> >> partial consensus on saving this field (renamed) for C and internal
> >> language. I am not sure about consensus about \sf enhancing.
> >
> > FWIW, I'm completely in favor of ditching PL source code. I'm neutral on C
> > and internal.
>
> here is a patch

As was mentioned, this thread doesn't really need a patch but rather
some comment from those who have voiced a -1 on removing the PL source
code column.

In another, perhaps vain, attempt to get to a consensus, here's what it
looks like the current standings are for "Remove source from \df+", to
me:
 Peter:    -1 Robert:   -0 Michael:  +0 Alvaro:   +1 Jim:      +1 Pavel:    +1 Rushabh:  +1 Stephen:  +1 Tom:      +1

There have been a number of voices asking that we do *something* here.

In short, I believe Robert's willing to concede to the majority (see:
CA+TgmoaPCBUGF7yTcjmiU=m2Sgo8jaNtnkHmTm1xKoaR5UQgoQ@mail.gmail.com), but
we have yet to hear if Peter's stance has changed on this since his July
posts (see: f16571cc-bf6f-53a1-6809-f09f48f0a832@2ndquadrant.com) and
that's a remaining full -1 vote.

Apologies if I got this wrong or mis-represented anyone, just trying to
drive towards a consensus on this, so we can move on.  Please speak up
if you feel this was an incorrect assessment of your position.

Full original thread is here:
https://www.postgresql.org/message-id/flat/CAB7nPqTR3Vu3xKOZOYqSm-%2BbSZV0kqgeGAXD6w5GLbkbfd5Q6w%40mail.gmail.com

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:
> As was mentioned, this thread doesn't really need a patch but rather
> some comment from those who have voiced a -1 on removing the PL source
> code column.

> In another, perhaps vain, attempt to get to a consensus, here's what it
> looks like the current standings are for "Remove source from \df+",

I think this is oversimplified, because there are multiple proposals on
the table, and it's not entirely clear to me who approves of which.
We have at least the following options:

1. Do nothing.
2. Remove the prosrc column from \df+ altogether.
3. Suppress prosrc for PL functions, but continue to show it for  C and internal functions (and, probably, rename it to
something other than "Source code" in that case).
 
4. #3 plus show PL function source code in footers.

Personally I like #4 better than #3 better than #2 better than #1,
but the only one I'm really against is "do nothing".

> There have been a number of voices asking that we do *something* here.

Yes.  I agree with your summary that Peter is the only one who appears
to be in favor of "do nothing" (and even there, his complaint was at
least partly procedural not substantive).
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > As was mentioned, this thread doesn't really need a patch but rather
> > some comment from those who have voiced a -1 on removing the PL source
> > code column.
>
> > In another, perhaps vain, attempt to get to a consensus, here's what it
> > looks like the current standings are for "Remove source from \df+",
>
> I think this is oversimplified, because there are multiple proposals on
> the table, and it's not entirely clear to me who approves of which.

That's certainly fair and I had begun that email by trying to come up
with a way to represent everyone's positions fairly but, frankly, after
an hour of reading through the thread and noting the various changes in
positions, I got to the point where I felt...

> > There have been a number of voices asking that we do *something* here.
>
> Yes.  I agree with your summary that Peter is the only one who appears
> to be in favor of "do nothing" (and even there, his complaint was at
> least partly procedural not substantive).

We really need a response on this part if we're going to actually make
any progress.

If we'd actually like to do a formal condorcet-style vote (or something
similar which allows preferences to be considered) over the various
options, I'm willing to put effort into making it happen, but only if
we'd actually agree to accept the result, otherwise we're just back here
again.

Thanks!

Stephen

On 10/11/16 7:51 PM, Tom Lane wrote:
> 1. Do nothing.
> 2. Remove the prosrc column from \df+ altogether.
> 3. Suppress prosrc for PL functions, but continue to show it for
>    C and internal functions (and, probably, rename it to something
>    other than "Source code" in that case).
> 4. #3 plus show PL function source code in footers.

One related annoyance I have with psql is that \d+ on a view *does* show
the "source code" in the footer, because it's often too long and bulky
and ugly and unrelated to why I wanted to use the +.

I'm OK with just removing all the source codes from the \d family and
using the \s family instead.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 10/11/16 7:51 PM, Tom Lane wrote:
> > 1. Do nothing.
> > 2. Remove the prosrc column from \df+ altogether.
> > 3. Suppress prosrc for PL functions, but continue to show it for
> >    C and internal functions (and, probably, rename it to something
> >    other than "Source code" in that case).
> > 4. #3 plus show PL function source code in footers.
>
> One related annoyance I have with psql is that \d+ on a view *does* show
> the "source code" in the footer, because it's often too long and bulky
> and ugly and unrelated to why I wanted to use the +.

I tend to agree with that, though I believe it's a topic for another
thread.

> I'm OK with just removing all the source codes from the \d family and
> using the \s family instead.

Ok, great, thanks for clarifying that.  Since we only have '\sf' today,
I think the prevailing option here is then to make the change to
removing 'prosrc' from \df+, have an 'internal name' column, and have
users use \sf for functions.

If anyone feels differently, please speak up.

Personally, I like the idea of a '\sv' for views, though we should
discuss that on a new thread.

Thanks!

Stephen

On 10/12/16 11:08 AM, Stephen Frost wrote:
> Personally, I like the idea of a '\sv' for views, though we should
> discuss that on a new thread.

\sv already exists. :-)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 10/12/16 11:08 AM, Stephen Frost wrote:
> > Personally, I like the idea of a '\sv' for views, though we should
> > discuss that on a new thread.
>
> \sv already exists. :-)

Whoops, sorry, was looking at a 9.5 psql. :)

Neat!

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
>> I'm OK with just removing all the source codes from the \d family and
>> using the \s family instead.

> Ok, great, thanks for clarifying that.  Since we only have '\sf' today,
> I think the prevailing option here is then to make the change to
> removing 'prosrc' from \df+, have an 'internal name' column, and have
> users use \sf for functions.

I'm not sure that Peter was voting for retaining "internal name", but
personally I prefer that to deleting prosrc entirely, so +1.

> Personally, I like the idea of a '\sv' for views, though we should
> discuss that on a new thread.

We have \sv already no?

I'm kind of -1 on removing view definitions from \d+.  It's worked like
that for a very long time and Peter's is the first complaint I've heard.
I think changing it is likely to annoy more people than will think it's
an improvement.
        regards, tom lane

On Wed, Oct 12, 2016 at 8:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
>>> I'm OK with just removing all the source codes from the \d family and
>>> using the \s family instead.
>
>> Ok, great, thanks for clarifying that.  Since we only have '\sf' today,
>> I think the prevailing option here is then to make the change to
>> removing 'prosrc' from \df+, have an 'internal name' column, and have
>> users use \sf for functions.
>
> I'm not sure that Peter was voting for retaining "internal name", but
> personally I prefer that to deleting prosrc entirely, so +1.
>
>> Personally, I like the idea of a '\sv' for views, though we should
>> discuss that on a new thread.
>
> We have \sv already no?
>
> I'm kind of -1 on removing view definitions from \d+.  It's worked like
> that for a very long time and Peter's is the first complaint I've heard.
> I think changing it is likely to annoy more people than will think it's
> an improvement.

I'm still not used to the change that I have to use \d+ rather than \d
to see the view definition.  It's the #1 thing I want to see when
examining a view, and since 2fe1b4dd651917aad2accac7ba8adb44d9f54930 I
have to remember to stick a + sign in there.  So, in short, I agree.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> >> I'm OK with just removing all the source codes from the \d family and
> >> using the \s family instead.
>
> > Ok, great, thanks for clarifying that.  Since we only have '\sf' today,
> > I think the prevailing option here is then to make the change to
> > removing 'prosrc' from \df+, have an 'internal name' column, and have
> > users use \sf for functions.
>
> I'm not sure that Peter was voting for retaining "internal name", but
> personally I prefer that to deleting prosrc entirely, so +1.

Apologies, didn't mean to say that he had agree with keeping 'internal
name', just that it seemed to be the most generally accepted apporach
(and it has a +1 from me as well).

> > Personally, I like the idea of a '\sv' for views, though we should
> > discuss that on a new thread.
>
> We have \sv already no?

Right, sorry.

> I'm kind of -1 on removing view definitions from \d+.  It's worked like
> that for a very long time and Peter's is the first complaint I've heard.
> I think changing it is likely to annoy more people than will think it's
> an improvement.

* Robert Haas (robertmhaas@gmail.com) wrote:
> I'm still not used to the change that I have to use \d+ rather than \d
> to see the view definition.  It's the #1 thing I want to see when
> examining a view, and since 2fe1b4dd651917aad2accac7ba8adb44d9f54930 I
> have to remember to stick a + sign in there.  So, in short, I agree.

I definitely see the argument of "\d on a view used to give me the view
def and now it's almost useless and I have to remember to \d+ all the
time", but I also think that I might be able to retrain my fingers to
do \sv for views more easily than always remembering to add a '+' to \d,
which I use much more frequently than \sv or \d+.

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> I'm still not used to the change that I have to use \d+ rather than \d
>> to see the view definition.  It's the #1 thing I want to see when
>> examining a view, and since 2fe1b4dd651917aad2accac7ba8adb44d9f54930 I
>> have to remember to stick a + sign in there.  So, in short, I agree.

> I definitely see the argument of "\d on a view used to give me the view
> def and now it's almost useless and I have to remember to \d+ all the
> time", but I also think that I might be able to retrain my fingers to
> do \sv for views more easily than always remembering to add a '+' to \d,
> which I use much more frequently than \sv or \d+.

I'm unimpressed with the "I can retrain" argument, because that only
applies to people who exclusively use the latest and greatest.  \sv
didn't exist before 9.6, so if I relearn to use that, it'll fail on me
anytime I'm using a pre-9.6 psql, which is going to be a significant
percentage of the time for awhile to come.

Some quick digging says that \d on a view included the view definition
in a footer since the very beginning (7.0 era, see commit a45195a19) and
we changed it in 9.0 to require +.  That's a heck of a lot of history
and fingertip knowledge to override on the strength of one man's
complaint, even if he is the man who made it that way in the first place.
I also note that getting into the habit of using "\d+" to see view
definitions didn't create any major problems when using older psqls.

(BTW, \sf has been there since 9.1, which means that equating the
compatibility situations for views and functions is a fallacy.)
        regards, tom lane

On 10/12/16 11:16 AM, Tom Lane wrote:
> I'm not sure that Peter was voting for retaining "internal name", but
> personally I prefer that to deleting prosrc entirely, so +1.

I'm not sure what the point of showing the internal name would be if we
have already declared that the source code of non-C functions is not
that interesting.  But I don't have a strong feeling about it.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Nov 8, 2016 at 4:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> There is still an open CommitFest entry for this patch, which is
>> marked "Ready for Committer", but it looks to me like there's no
>> consensus position here.  Different people have different preferences,
>> and every option that is somebody's first preference seems to be
>> somebody else's last preference.  So I suggest that we give this one
>> up for a lost cause and mark it Rejected.
>
> Yeah, that's about where I'm at on it too.

Done.  We can reopen this if a vigorous consensus emerges.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> There is still an open CommitFest entry for this patch, which is
> marked "Ready for Committer", but it looks to me like there's no
> consensus position here.  Different people have different preferences,
> and every option that is somebody's first preference seems to be
> somebody else's last preference.  So I suggest that we give this one
> up for a lost cause and mark it Rejected.

Yeah, that's about where I'm at on it too.
        regards, tom lane

On Wed, Oct 12, 2016 at 1:48 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 10/12/16 11:16 AM, Tom Lane wrote:
>> I'm not sure that Peter was voting for retaining "internal name", but
>> personally I prefer that to deleting prosrc entirely, so +1.
>
> I'm not sure what the point of showing the internal name would be if we
> have already declared that the source code of non-C functions is not
> that interesting.  But I don't have a strong feeling about it.

There is still an open CommitFest entry for this patch, which is
marked "Ready for Committer", but it looks to me like there's no
consensus position here.  Different people have different preferences,
and every option that is somebody's first preference seems to be
somebody else's last preference.  So I suggest that we give this one
up for a lost cause and mark it Rejected.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company