Showing parallel status in \df+

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

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

2016-07-08 9:00 GMT+02:00 Michael Paquier <michael.paquier@gmail.com>:

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?

It has 11 columns. I don't see any problem to show few columns more. It is
better than missing important information.

Regards

Pavel

--

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

* 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 whacking things around too much post-beta, we should lean in the direction of whacking them around less. You don't have to agree with Peter on the merits to think that this is optional tinkering. It clearly is.

...Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi

2016-07-13 19:01 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

I am sending a review of this patch:

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.

This patch is trivial and there is not any problem with patching,
compilation and test. I have few ideas:

1. show full source code of function - like \sf output - the only body
outside table looks strange

2. is there possibility to isolate sources by some visual element (border,
line)?

Current output:

Source code of function public.bubble(a anyarray, OUT b anyarray):

declare loop_again boolean := true;
begin
while loop_again
loop
loop_again := false;
for i in array_lower(a,1) .. array_upper(a,1) - 1
loop
if (a[i] > a[i+1]) then
b[1] = a[i+1];
a[i+1] = a[i]; a[i] := b[1];
loop_again = true;
end if;
end loop;
end loop;
b := a;
end

Source code of function public.bubble2(a anyarray, OUT b anyarray):

declare loop_again boolean := true;
begin
while loop_again
loop
loop_again := false;
for i in array_lower(a,1) .. array_upper(a,1) - 1
loop
if (a[i] > a[i+1]) then
b[1] = a[i+1];
a[i+1] = a[i]; a[i] := b[1];
loop_again = true;
end if;
end loop;
end loop;
b := a;
end

Preferred output:

Source code of function public.bubble(a anyarray, OUT b anyarray):
------------------------------------------------------------------
CREATE OR REPLACE FUNCTION public.bubble(a anyarray, OUT b anyarray)
RETURNS anyarray
LANGUAGE plpgsql
AS $function$
declare loop_again boolean := true;
begin
while loop_again
loop
loop_again := false;
for i in array_lower(a,1) .. array_upper(a,1) - 1
loop
if (a[i] > a[i+1]) then
b[1] = a[i+1];
a[i+1] = a[i]; a[i] := b[1];
loop_again = true;
end if;
end loop;
end loop;
b := a;
end;

Source code of function public.bubble2(a anyarray, OUT b anyarray):
-------------------------------------------------------------------
CREATE OR REPLACE FUNCTION public.bubble2(a anyarray, OUT b anyarray)
RETURNS anyarray
LANGUAGE plpgsql
AS $function$
declare loop_again boolean := true;
begin
while loop_again
loop
loop_again := false;
for i in array_lower(a,1) .. array_upper(a,1) - 1
loop
if (a[i] > a[i+1]) then
b[1] = a[i+1];
a[i+1] = a[i]; a[i] := b[1];
loop_again = true;
end if;
end loop;
end loop;
b := a;
end;

3. append semicolon on the end - so copy/paste should to work

Regards

Pavel Stehule

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-08-22 18:19 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:

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.

If I understand to purpose of this patch - it is compromise - PL source is
removed from table, but it is printed in result.

I am sure so there are low benefit from displaying the body of PL function
inside table. But I see some benefit on Tom's design. We cannot to simply
show source code of more functions. \sf doesn't support it. The source is
displayed on the end, so there is low impact on result.

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 functions
Schema | 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 * from foo 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 functions
Schema | 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 | sine
pg_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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-08-24 15:42 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

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

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi

2016-09-06 0:05 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

I see only one situation, when I want to see more then one source code -
checking overloaded functions. I prefer to see complete source code - in
\sf format. But I don't remember, when I did it last time. So I can live
without it well.

I am thinking, there is strong agreement about reduction \dt+ result. I am
not sure about usability of showing source code in footer. It is not too
much readable - and the fact, so function's body is displayed not as CREATE
statements, does the result less readable.

Now I am thinking so using footer for this purpose is not too great idea -
maybe we can live better without it (without source code of PL in \dt+
result, I would to see only C function source there). If you like using
footer, then the format should be changed to be more consistent, readable?
I am not sure, how it can be enhanced.

Regards

Pavel

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

Personally I didn't like idea for keeping "source code" for C/internal
functions as part of \df+ and moving others out of it. If we really want to
move "source code" from \df+, then it should be consistent - irrespective
of language. So may be remove "source code" completely from \df+ and add
\df++ support for the "source code".

On Wed, Sep 7, 2016 at 12:14 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

Hi

2016-09-06 0:05 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

I see only one situation, when I want to see more then one source code -
checking overloaded functions. I prefer to see complete source code - in
\sf format. But I don't remember, when I did it last time. So I can live
without it well.

I am thinking, there is strong agreement about reduction \dt+ result. I am
not sure about usability of showing source code in footer. It is not too
much readable - and the fact, so function's body is displayed not as CREATE
statements, does the result less readable.

Now I am thinking so using footer for this purpose is not too great idea -
maybe we can live better without it (without source code of PL in \dt+
result, I would to see only C function source there). If you like using
footer, then the format should be changed to be more consistent, readable?
I am not sure, how it can be enhanced.

Regards

Pavel

regards, tom lane

--
Rushabh Lathia

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

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.

regards, tom lane

--
Rushabh Lathia

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:

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?

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.

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

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
www.EnterpriseDB.com

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-09-28 16:03 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

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

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi

2016-09-28 18:57 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

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

I cannot to imagine any use case for proposed format.

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

2016-09-28 21:59 GMT+02:00 Alvaro Herrera <alvherre@2ndquadrant.com>:

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 know so I can use \sf. But I don't see any sense to have less readable
output of any psql command.

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.

I prefer removing before proposed solution with proposed format.

We are in cycle because prosrc field is used for two independent features -
and then it can be hard to find a agreement.

Name of function in dll is some different than PL function body. But it is
stored and displayed in one field - and it is impossible do it well.

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Sep 29, 2016 at 12:07 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

Hi

2016-09-28 18:57 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

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

I cannot to imagine any use case for proposed format.

I just did testing on Tom's patch - which show pl source code as a footer
(show-pl-source-code-as-a-footer.patch). I am sorry, but I agree with Paval,
its is hard readable - and its not adding any simplification on what we have
now.

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

Thinking more, I am good for keeping prosrc in \df+ for internal/C-language
functions (with changed column name). and then \sf will be used to
get the source code for PL, SQL, language.

Regards

Pavel

regards, tom lane

--
Rushabh Lathia
www.EnterpriseDB.com

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 /messages/by-id/20160926190618.GH5148@tamriel.snowman.net
(thanks Stephen for the summary) that's where we are heading to.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 /messages/by-id/20160926190618.GH5148@tamriel.snowman.net
(thanks Stephen for the summary) that's where we are heading to.

(Moved to next CF)
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:

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.

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

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-10-03 22:03 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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.

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.

First point is almost clean -- others not, but is not necessary do it now.
Who needs some special functionality, he can do direct query on pg_proc. It
is not mayor functionality - there is more than one possible substitution -
so cleaning without any other changes should be ok too.

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi

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

Regards

Pavel

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:
/messages/by-id/CAB7nPqTR3Vu3xKOZOYqSm-+bSZV0kqgeGAXD6w5GLbkbfd5Q6w@mail.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-10-12 1:51 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

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

My preferences: #2, #1 - I dislike #4 more than #1 - I don't see any
benefit there

Regards

Pavel

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-10-12 19:48 GMT+02:00 Peter Eisentraut <
peter.eisentraut@2ndquadrant.com>:

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.

The benefit is for people who have to look on C implementation of internal
functions. Probably not too big group - but it can be interesting for
beginners who starting with reading of PostgreSQL code.

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers