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