On Sat, Jul 9, 2016 at 4:02 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2016-07-08 20:39 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>: >> >> Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> > As a separate concern, IMO having the source code in a \df+ column is >> > almost completely useless. >> >> Good point. It works okay for C/internal functions, but in those cases >> it's usually redundant with the proname. For PL functions it's a disaster >> formatting-wise, because they're often wide and/or multi-line. >> >> > I propose to split that out to a separate >> > \df command (say \df% or \df/) that shows *only* the source code. >> >> As to those names, ick. Also, what do you envision the output looking >> like when multiple functions are selected? Or would you ban wildcards? >> If you do, it's not clear what this does that \sf doesn't do better. >> >> Maybe, given the existence of \sf, we should just drop prosrc from \df+ >> altogether. > > prosrc has still benefit for me (for C hacking). Can we show data there only > for internal or C functions? I agree, it useless for PLpgSQL.
So to sum up: - Add "Parallel" column - Add ACLs - Reordering the columns, I'd suggest as follows): -- Schema -- Name -- Result data type -- Argument data types -- Type -- Language -- Volatility -- Parallel -- Owner -- Security -- ACL -- Source code -- Description Or by thema, 1) General info, 2) specificity (volatility, parallel, type), 3) Ownership. And regarding "source code", I think that's useful for debugging. -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers