Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

Hi

2016-10-08 23:46 GMT+02:00 Jim Nasby :

> 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


> --
> 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
>
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 6275a68..f03f547 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -455,10 +455,12 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 		printACLColumn(, "p.proacl");
 		appendPQExpBuffer(,
 		  ",\n l.lanname as \"%s\""
-		  ",\n p.prosrc as \"%s\""
+		  ",\n CASE\n"
+		  "  WHEN l.lanname IN ('c','internal') THEN p.prosrc\n"
+		  "END as \"%s\""
 ",\n pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
 		  gettext_noop("Language"),
-		  gettext_noop("Source code"),
+		  gettext_noop("Reference name"),
 		  gettext_noop("Description"));
 	}
 

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

Re: [HACKERS] Showing parallel status in \df+

[Jim Nasby]

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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-10-03 22:03 GMT+02:00 Tom Lane :

> Pavel Stehule  writes:
> > 2016-10-03 21:54 GMT+02:00 Robert Haas :
> >> On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane  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



>
> regards, tom lane
>

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Pavel Stehule  writes:
> 2016-10-03 21:54 GMT+02:00 Robert Haas :
>> On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane  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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-10-03 21:54 GMT+02:00 Robert Haas :

> On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane  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



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

Re: [HACKERS] Showing parallel status in \df+

[Robert Haas]

On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane  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

Re: [HACKERS] Showing parallel status in \df+

[Michael Paquier]

On Sun, Oct 2, 2016 at 10:55 PM, Michael Paquier
 wrote:
> Let's remove it and move on then. By looking again at this thread and
> particularly 
> https://www.postgresql.org/message-id/20160926190618.gh5...@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

Re: [HACKERS] Showing parallel status in \df+

[Michael Paquier]

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

Let's remove it and move on then. By looking again at this thread and
particularly 
https://www.postgresql.org/message-id/20160926190618.gh5...@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

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Jim Nasby  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

Re: [HACKERS] Showing parallel status in \df+

[Jim Nasby]

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

Re: [HACKERS] Showing parallel status in \df+

[Rushabh Lathia]

On Thu, Sep 29, 2016 at 12:07 AM, Pavel Stehule 
wrote:

> Hi
>
> 2016-09-28 18:57 GMT+02:00 Tom Lane :
>
>> Pavel Stehule  writes:
>> > 2016-09-28 16:03 GMT+02:00 Tom Lane :
>> >> 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  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

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Pavel Stehule  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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-09-28 21:59 GMT+02:00 Alvaro Herrera :

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


>
> If we're not removing it, I +0 support the option of moving it to
> footers.  I'm -1 on doing nothing.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Alvaro Herrera (alvhe...@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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Alvaro Herrera]

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 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 Herrerahttps://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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

Hi

2016-09-28 18:57 GMT+02:00 Tom Lane :

> Pavel Stehule  writes:
> > 2016-09-28 16:03 GMT+02:00 Tom Lane :
> >> 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


>
> regards, tom lane
>

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Pavel Stehule  writes:
> 2016-09-28 16:03 GMT+02:00 Tom Lane :
>> 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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-09-28 16:03 GMT+02:00 Tom Lane :

> Rushabh Lathia  writes:
> > On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost 
> 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

>
> regards, tom lane
>

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Rushabh Lathia  writes:
> On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost  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

Re: [HACKERS] Showing parallel status in \df+

[Rushabh Lathia]

On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost  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  wrote:

> * Tom Lane (t...@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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Robert Haas  writes:
> On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost  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

Re: [HACKERS] Showing parallel status in \df+

[Robert Haas]

On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost  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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

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

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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Robert Haas]

On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost  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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Pavel Stehule  writes:
> > 2016-09-23 7:22 GMT+02:00 Rushabh Lathia :
> >> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane  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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Pavel Stehule  writes:
> 2016-09-23 7:22 GMT+02:00 Rushabh Lathia :
>> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane  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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-09-23 7:22 GMT+02:00 Rushabh Lathia :

>
>
> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane  wrote:
>
>> Rushabh Lathia  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


>
>
>
>> regards, tom lane
>>
>
>
>
> --
> Rushabh Lathia
>

Re: [HACKERS] Showing parallel status in \df+

[Rushabh Lathia]

On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane  wrote:

> Rushabh Lathia  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

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Rushabh Lathia  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

Re: [HACKERS] Showing parallel status in \df+

[Rushabh Lathia]

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 
wrote:

> Hi
>
> 2016-09-06 0:05 GMT+02:00 Tom Lane :
>
>> I wrote:
>> > Pavel Stehule  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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

Hi

2016-09-06 0:05 GMT+02:00 Tom Lane :

> I wrote:
> > Pavel Stehule  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
>

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

I wrote:
> Pavel Stehule  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

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Pavel Stehule  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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-08-24 15:42 GMT+02:00 Tom Lane :

> Peter Eisentraut  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




> regards, tom lane
>

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

I wrote:
> Peter Eisentraut  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   | 

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Peter Eisentraut  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

Re: [HACKERS] Showing parallel status in \df+

[Peter Eisentraut]

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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-08-22 18:19 GMT+02:00 Robert Haas :

> On Mon, Aug 22, 2016 at 4:49 AM, Pavel Stehule 
> 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




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

Re: [HACKERS] Showing parallel status in \df+

[Robert Haas]

On Mon, Aug 22, 2016 at 4:49 AM, Pavel Stehule  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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

Hi



2016-07-13 19:01 GMT+02:00 Tom Lane :

> Peter Eisentraut  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



>
> regards, tom lane
>
>

Re: [HACKERS] Showing parallel status in \df+

[Robert Haas]

On Jul 13, 2016, at 12:25 PM, Stephen Frost  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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Peter Eisentraut (peter.eisentr...@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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

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

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

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

regards, tom lane

diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 27be102..f5dfd83 100644
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*** describeFunctions(const char *functypes,
*** 294,308 
  	bool		showNormal = strchr(functypes, 'n') != NULL;
  	bool		showTrigger = strchr(functypes, 't') != NULL;
  	bool		showWindow = strchr(functypes, 'w') != NULL;
  	bool		have_where;
  	PQExpBufferData buf;
  	PGresult   *res;
  	printQueryOpt myopt = pset.popt;
  	static const bool translate_columns[] = {false, false, false, false, true, true, true, false, true, false, false, false, false};
  
- 	/* No "Parallel" column before 9.6 */
- 	static const bool translate_columns_pre_96[] = {false, false, false, false, true, true, false, true, false, false, false, false};
- 
  	if (strlen(functypes) != strspn(functypes, "antwS+"))
  	{
  		psql_error("\\df only takes [antwS+] as options\n");
--- 294,316 
  	bool		showNormal = strchr(functypes, 'n') != NULL;
  	bool		showTrigger = strchr(functypes, 't') != NULL;
  	bool		showWindow = strchr(functypes, 'w') != NULL;
+ 	bool		have_parallel;
  	bool		have_where;
  	PQExpBufferData buf;
  	PGresult   *res;
+ 	printTableContent cont;
  	printQueryOpt myopt = pset.popt;
+ 	int			nfields,
+ r,
+ c;
+ 	const int	schema_col = 0;
+ 	const int	proname_col = 1;
+ 	const int	proargs_col = 3;
+ 	const int	parallel_col = 6;
+ 	const int	lanname_col = 10;
+ 	const int	prosrc_col = 11;
  	static const bool translate_columns[] = {false, false, false, false, true, true, true, false, true, false, false, false, false};
  
  	if (strlen(functypes) != strspn(functypes, "antwS+"))
  	{
  		psql_error("\\df only takes [antwS+] as options\n");
*** describeFunctions(const char *functypes,
*** 323,328 
--- 331,344 
  			showWindow = true;
  	}
  
+ 	/*
+ 	 * proparallel only exists in server versions >= 9.6.  Before that, we
+ 	 * retrieve a null "parallel" column so as to keep column numbering
+ 	 * consistent in the query result, and then skip adding that column to the
+ 	 * printed table.
+ 	 */
+ 	have_parallel = (pset.sversion >= 90600);
+ 
  	initPQExpBuffer();
  
  	printfPQExpBuffer(,
*** describeFunctions(const char *functypes,
*** 424,430 
  		  gettext_noop("stable"),
  		  gettext_noop("volatile"),
  		  gettext_noop("Volatility"));
! 		if (pset.sversion >= 90600)
  			appendPQExpBuffer(,
  			  ",\n CASE\n"
  			  "  WHEN p.proparallel = 'r' THEN '%s'\n"
--- 440,446 
  		  gettext_noop("stable"),
  		  gettext_noop("volatile"),
  		  gettext_noop("Volatility"));
! 		if (have_parallel)
  			appendPQExpBuffer(,
  			  ",\n CASE\n"
  			  "  WHEN p.proparallel = 'r' THEN '%s'\n"
*** describeFunctions(const char *functypes,
*** 435,440 
--- 451,459 
  			  gettext_noop("safe"),
  			  gettext_noop("unsafe"),
  			  gettext_noop("Parallel"));
+ 		else
+ 			appendPQExpBufferStr(,
+  ",\n NULL as \"Parallel\"");
  		appendPQExpBuffer(,
  	   ",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\""
   ",\n CASE WHEN prosecdef THEN '%s' ELSE '%s' END AS \"%s\"",
*** describeFunctions(const char *functypes,
*** 449,455 
  		  ",\n p.prosrc as \"%s\""
  ",\n pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
  		  gettext_noop("Language"),
! 		  gettext_noop("Source code"),
  		  gettext_noop("Description"));
  	}
  
--- 468,474 
  		  ",\n p.prosrc as \"%s\""
  ",\n pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
  		  gettext_noop("Language"),
! 		  gettext_noop("Internal name"),
  		  gettext_noop("Description"));
  	}
  
*** describeFunctions(const char *functypes,
*** 543,569 
  	appendPQExpBufferStr(, "ORDER BY 1, 2, 4;");
  
  	res = PSQLexec(buf.data);
- 	termPQExpBuffer();
  	if (!res)
  		return false;
  
! 	myopt.nullPrint = NULL;
! 	myopt.title = _("List of functions");
! 	myopt.translate_header = true;
! 	if (pset.sversion >= 90600)
  	{
! 		myopt.translate_columns = translate_columns;
! 		myopt.n_translate_columns = lengthof(translate_columns);
  	}
! 	else
  	{
! 		myopt.translate_columns = translate_columns_pre_96;
! 		myopt.n_translate_columns = lengthof(translate_columns_pre_96);
  	}
  
! 	

Re: [HACKERS] Showing parallel status in \df+

[Peter Eisentraut]

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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Peter Eisentraut (peter.eisentr...@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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Alvaro Herrera]

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 Herrerahttp://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

Re: [HACKERS] Showing parallel status in \df+

[Peter Eisentraut]

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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost  writes:
> > * Tom Lane (t...@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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Stephen Frost  writes:
> * Tom Lane (t...@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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost  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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Stephen Frost  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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier  writes:
> > On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
> >  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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Michael Paquier  writes:
> On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
>  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

Re: [HACKERS] Showing parallel status in \df+

[Michael Paquier]

On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
 wrote:
> Stephen Frost wrote:
>> * Tom Lane (t...@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

Re: [HACKERS] Showing parallel status in \df+

[Alvaro Herrera]

Stephen Frost wrote:
> * Tom Lane (t...@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 Herrerahttp://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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost  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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Stephen Frost  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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier  writes:
> > On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane  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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Michael Paquier  writes:
> On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane  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

Re: [HACKERS] Showing parallel status in \df+

[Michael Paquier]

On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane  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
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index aeffd63..e7bd2d7 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1380,8 +1380,9 @@ testdb=
 objects are shown; supply a pattern or the S
 modifier to include system objects.
 If the form \df+ is used, additional information
-about each function is shown, including security classification,
-volatility, owner, language, source code and description.
+about each function is shown, including language, volatility,
+parallel mode, owner, security classification, access privileges,
+source code and description.
 
 
 
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 2cdc5ac..8559b68 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -298,7 +298,7 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 	PQExpBufferData buf;
 	PGresult   *res;
 	printQueryOpt myopt = pset.popt;
-	static const bool translate_columns[] = {false, false, false, false, true, true, true, false, false, false, false};
+	static const bool translate_columns[] = {false, false, false, false, true, true, false, false, true, false, false, true, false};
 
 	if (strlen(functypes) != strspn(functypes, "antwS+"))
 	{
@@ -410,28 +410,42 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 		  gettext_noop("Type"));
 
 	if (verbose)
+	{
 		appendPQExpBuffer(,
-  ",\n CASE WHEN prosecdef THEN '%s' ELSE '%s' END AS \"%s\""
 		  ",\n CASE\n"
 		  "  WHEN p.provolatile = 'i' THEN '%s'\n"
 		  "  WHEN p.provolatile = 's' THEN '%s'\n"
 		  "  WHEN p.provolatile = 'v' THEN '%s'\n"
 		  " END as \"%s\""
-   ",\n  pg_catalog.pg_get_userbyid(p.proowner) as \"%s\",\n"
-		  "  l.lanname as \"%s\",\n"
-		  "  p.prosrc as \"%s\",\n"
-  "  pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
-		  gettext_noop("definer"),
-		  gettext_noop("invoker"),
-		  gettext_noop("Security"),
+		  ",\n CASE\n"
+		  "  WHEN p.proparallel = 'r' THEN '%s'\n"
+		  "  WHEN p.proparallel = 's' THEN '%s'\n"
+		  "  WHEN p.proparallel = 'u' THEN '%s'\n"
+		  " END as \"%s\""
+   ",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\""
+		  ",\n CASE WHEN prosecdef THEN '%s' ELSE '%s' END AS \"%s\"",
 		  gettext_noop("immutable"),
 		  gettext_noop("stable"),
 		  gettext_noop("volatile"),
 		  gettext_noop("Volatility"),
+		  gettext_noop("restricted"),
+		  gettext_noop("safe"),
+		  gettext_noop("unsafe"),
+		  gettext_noop("Parallel"),
 		  gettext_noop("Owner"),
+		  gettext_noop("definer"),
+		  gettext_noop("invoker"),
+		  gettext_noop("Security"));
+		appendPQExpBufferStr(, ",\n  ");
+		printACLColumn(, "p.proacl");
+		appendPQExpBuffer(,
+		  ",\n l.lanname as \"%s\""
+		  ",\n p.prosrc as \"%s\""
+  ",\n pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
 		  gettext_noop("Language"),
 		  gettext_noop("Source code"),
 		  gettext_noop("Description"));
+	}
 
 	appendPQExpBufferStr(,
 		 "\nFROM pg_catalog.pg_proc p"

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

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Michael Paquier  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

Re: [HACKERS] Showing parallel status in \df+

[Michael Paquier]

On Sat, Jul 9, 2016 at 8:12 AM, Michael Paquier
 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
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index aeffd63..e7bd2d7 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1380,8 +1380,9 @@ testdb=
 objects are shown; supply a pattern or the S
 modifier to include system objects.
 If the form \df+ is used, additional information
-about each function is shown, including security classification,
-volatility, owner, language, source code and description.
+about each function is shown, including language, volatility,
+parallel mode, owner, security classification, access privileges,
+source code and description.
 
 
 
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 2cdc5ac..e297891 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -298,7 +298,7 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 	PQExpBufferData buf;
 	PGresult   *res;
 	printQueryOpt myopt = pset.popt;
-	static const bool translate_columns[] = {false, false, false, false, true, true, true, false, false, false, false};
+	static const bool translate_columns[] = {false, false, false, false, true, false, true, false, false, true, false, true, false};
 
 	if (strlen(functypes) != strspn(functypes, "antwS+"))
 	{
@@ -410,28 +410,42 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 		  gettext_noop("Type"));
 
 	if (verbose)
+	{
 		appendPQExpBuffer(,
-  ",\n CASE WHEN prosecdef THEN '%s' ELSE '%s' END AS \"%s\""
+		  ",\n l.lanname as \"%s\""
 		  ",\n CASE\n"
 		  "  WHEN p.provolatile = 'i' THEN '%s'\n"
 		  "  WHEN p.provolatile = 's' THEN '%s'\n"
 		  "  WHEN p.provolatile = 'v' THEN '%s'\n"
 		  " END as \"%s\""
-   ",\n  pg_catalog.pg_get_userbyid(p.proowner) as \"%s\",\n"
-		  "  l.lanname as \"%s\",\n"
-		  "  p.prosrc as \"%s\",\n"
-  "  pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
-		  gettext_noop("definer"),
-		  gettext_noop("invoker"),
-		  gettext_noop("Security"),
+		  ",\n CASE\n"
+		  "  WHEN p.proparallel = 'r' THEN '%s'\n"
+		  "  WHEN p.proparallel = 's' THEN '%s'\n"
+		  "  WHEN p.proparallel = 'u' THEN '%s'\n"
+		  " END as \"%s\""
+   ",\n pg_catalog.pg_get_userbyid(p.proowner) as \"%s\""
+		  ",\n CASE WHEN prosecdef THEN '%s' ELSE '%s' END AS \"%s\"",
+		  gettext_noop("Language"),
 		  gettext_noop("immutable"),
 		  gettext_noop("stable"),
 		  gettext_noop("volatile"),
 		  gettext_noop("Volatility"),
+		  gettext_noop("restricted"),
+		  gettext_noop("safe"),
+		  gettext_noop("unsafe"),
+		  gettext_noop("Parallel"),
 		  gettext_noop("Owner"),
-		  gettext_noop("Language"),
+		  gettext_noop("definer"),
+		  gettext_noop("invoker"),
+		  gettext_noop("Security"));
+		appendPQExpBufferStr(, ",\n  ");
+		printACLColumn(, "p.proacl");
+		appendPQExpBuffer(,
+		  ",\n p.prosrc as \"%s\""
+  ",\n pg_catalog.obj_description(p.oid, 'pg_proc') as \"%s\"",
 		  gettext_noop("Source code"),
 		  gettext_noop("Description"));
+	}
 
 	appendPQExpBufferStr(,
 		 "\nFROM pg_catalog.pg_proc p"

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

Re: [HACKERS] Showing parallel status in \df+

[Michael Paquier]

On Sat, Jul 9, 2016 at 4:02 AM, Pavel Stehule  wrote:
>
>
> 2016-07-08 20:39 GMT+02:00 Tom Lane :
>>
>> Alvaro Herrera  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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-07-08 20:39 GMT+02:00 Tom Lane :

> Alvaro Herrera  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

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

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Alvaro Herrera  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

Re: [HACKERS] Showing parallel status in \df+

[Alvaro Herrera]

Tom Lane wrote:
> Magnus Hagander  writes:
> > On Friday, July 8, 2016, Michael Paquier  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 Herrerahttp://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

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Amit Kapila  writes:
> > On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
> >  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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander  writes:
> > On Friday, July 8, 2016, Michael Paquier  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


signature.asc
Description: Digital signature

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Amit Kapila  writes:
> On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
>  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

Re: [HACKERS] Showing parallel status in \df+

[Tom Lane]

Magnus Hagander  writes:
> On Friday, July 8, 2016, Michael Paquier  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

Re: [HACKERS] Showing parallel status in \df+

[Amit Kapila]

On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
 wrote:
> On Fri, Jul 8, 2016 at 4:04 PM, Magnus Hagander  wrote:
>> On Friday, July 8, 2016, Michael Paquier  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

Re: [HACKERS] Showing parallel status in \df+

[Michael Paquier]

On Fri, Jul 8, 2016 at 4:04 PM, Magnus Hagander  wrote:
> On Friday, July 8, 2016, Michael Paquier  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
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index aeffd63..e36efc3 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1381,7 +1381,7 @@ testdb=
 modifier to include system objects.
 If the form \df+ is used, additional information
 about each function is shown, including security classification,
-volatility, owner, language, source code and description.
+volatility, parallelism, owner, language, source code and description.
 
 
 
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 2cdc5ac..8d0e655 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -298,7 +298,7 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 	PQExpBufferData buf;
 	PGresult   *res;
 	printQueryOpt myopt = pset.popt;
-	static const bool translate_columns[] = {false, false, false, false, true, true, true, false, false, false, false};
+	static const bool translate_columns[] = {false, false, false, false, true, true, true, true, false, false, false, false};
 
 	if (strlen(functypes) != strspn(functypes, "antwS+"))
 	{
@@ -417,6 +417,11 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 		  "  WHEN p.provolatile = 's' THEN '%s'\n"
 		  "  WHEN p.provolatile = 'v' THEN '%s'\n"
 		  " END as \"%s\""
+		  ",\n CASE\n"
+		  "  WHEN p.proparallel = 'r' THEN '%s'\n"
+		  "  WHEN p.proparallel = 's' THEN '%s'\n"
+		  "  WHEN p.proparallel = 'u' THEN '%s'\n"
+		  " END as \"%s\""
    ",\n  pg_catalog.pg_get_userbyid(p.proowner) as \"%s\",\n"
 		  "  l.lanname as \"%s\",\n"
 		  "  p.prosrc as \"%s\",\n"
@@ -428,6 +433,10 @@ describeFunctions(const char *functypes, const char *pattern, bool verbose, bool
 		  gettext_noop("stable"),
 		  gettext_noop("volatile"),
 		  gettext_noop("Volatility"),
+		  gettext_noop("restricted"),
+		  gettext_noop("safe"),
+		  gettext_noop("unsafe"),
+		  gettext_noop("Parallelism"),
 		  gettext_noop("Owner"),
 		  gettext_noop("Language"),
 		  gettext_noop("Source code"),

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

Re: [HACKERS] Showing parallel status in \df+

[Pavel Stehule]

2016-07-08 9:00 GMT+02:00 Michael Paquier :

> 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

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

Re: [HACKERS] Showing parallel status in \df+

[Magnus Hagander]

On Friday, July 8, 2016, Michael Paquier  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/