\d+ for long view definitions?

Peter Eisentraut <peter_e@gmx.net> writes:

Using \d on, say, information schema views is completely hilarious
because the column name/data type information is usually scrolled off
the screen by the immense view definition.

Could we change this perhaps so that the full view definition is only
shown with \d+ when the view definition is longer than N characters or N
lines or some other suitable cutoff. Ideas?

The same complaint could be made for any table with more than
twenty-some columns. Seems like a more general answer would be
for \d output to go through the pager ...

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Using \d on, say, information schema views is completely hilarious
because the column name/data type information is usually scrolled off
the screen by the immense view definition.

Could we change this perhaps so that the full view definition is only
shown with \d+ when the view definition is longer than N characters or N
lines or some other suitable cutoff. Ideas?

The same complaint could be made for any table with more than
twenty-some columns. Seems like a more general answer would be
for \d output to go through the pager ...

I think the fix is to have psql add the number of lines in headers and
footers to the calculation that decides whether to use the pager or not.
Right now I think it only considers data rows.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On sön, 2009-08-30 at 18:43 -0400, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Using \d on, say, information schema views is completely hilarious
because the column name/data type information is usually scrolled off
the screen by the immense view definition.

Could we change this perhaps so that the full view definition is only
shown with \d+ when the view definition is longer than N characters or N
lines or some other suitable cutoff. Ideas?

The same complaint could be made for any table with more than
twenty-some columns.

I guess my premise is that if I use \d, I'm primarily interested in the
column names and types. The view definition is secondary. If the view
definition is a single line or uses a single table, it's interesting
because it might describe something about the schema design, but if it's
20 lines it's an implementation detail.

I think this is quite similar to showing the function definition only
with \df+. If I'm looking at the function, I'm usually only looking for
name and parameter information, not the full source code.

Seems like a more general answer would be
for \d output to go through the pager ...

That should also be fixed, but I'm not sure if it really does it for me.

Peter Eisentraut <peter_e@gmx.net> writes:

On sön, 2009-08-30 at 18:43 -0400, Tom Lane wrote:

Seems like a more general answer would be
for \d output to go through the pager ...

That should also be fixed, but I'm not sure if it really does it for me.

Why not? Just quit out of the pager when you've seen enough.

If the view definition precedes other data that is deemed more
important, then we'd need to adjust the ordering, but I'm not
entirely seeing the point of having to suppress the definition.

I especially don't like the thought of making it depend on the length
of the definition. I would prefer \d not showing it at all.

regards, tom lane

On 8/31/09 1:13 PM, Peter Eisentraut wrote:

I guess my premise is that if I use \d, I'm primarily interested in the
column names and types. The view definition is secondary. If the view
definition is a single line or uses a single table, it's interesting
because it might describe something about the schema design, but if it's
20 lines it's an implementation detail.

I agree with Peter here.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Tue, Sep 1, 2009 at 1:31 PM, Josh Berkus<josh@agliodbs.com> wrote:

On 8/31/09 1:13 PM, Peter Eisentraut wrote:

I guess my premise is that if I use \d, I'm primarily interested in the
column names and types.  The view definition is secondary.  If the view
definition is a single line or uses a single table, it's interesting
because it might describe something about the schema design, but if it's
20 lines it's an implementation detail.

I agree with Peter here.

I think we should always or never show the view definition, not sometimes.

And I also agree with Tom's point that we should fix the pager. The
way that it works now is really annoying.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

I think we should always or never show the view definition, not sometimes.

Yeah. I can live with \d not showing it and \d+ showing it --- as Peter
already mentioned, that would be consistent with \df behavior. Making
it depend on the length is just weird.

regards, tom lane

Robert Haas <robertmhaas@gmail.com> wrote:

I think we should always or never show the view definition, not
sometimes.

+1

And I also agree with Tom's point that we should fix the pager. The
way that it works now is really annoying.

+1

-Kevin

On Tue, Sep 01, 2009 at 02:29:12PM -0400, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

I think we should always or never show the view definition, not
sometimes.

Yeah. I can live with \d not showing it and \d+ showing it --- as
Peter already mentioned, that would be consistent with \df behavior.
Making it depend on the length is just weird.

As I see it, there are two independent issues here:

* "Smart" display based on number of columns in the query and the psql window
* Whether to display the view definition.

I'm thinking on the second, \d should not display the definition, and
\d+ should.

On the first...could we go to \x-type display if the columns will
overflow the terminal?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Tue, Sep 1, 2009 at 3:01 PM, David Fetter<david@fetter.org> wrote:

On Tue, Sep 01, 2009 at 02:29:12PM -0400, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

I think we should always or never show the view definition, not
sometimes.

Yeah.  I can live with \d not showing it and \d+ showing it --- as
Peter already mentioned, that would be consistent with \df behavior.
Making it depend on the length is just weird.

As I see it, there are two independent issues here:

* "Smart" display based on number of columns in the query and the psql window
* Whether to display the view definition.

I'm thinking on the second, \d should not display the definition, and
\d+ should.

On the first...could we go to \x-type display if the columns will
overflow the terminal?

I don't understand exactly what you're proposing, but I don't think
flipping into \x mode based on the window size is ever a good idea.

...Robert

On tis, 2009-09-01 at 14:29 -0400, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

I think we should always or never show the view definition, not sometimes.

Yeah. I can live with \d not showing it and \d+ showing it --- as Peter
already mentioned, that would be consistent with \df behavior. Making
it depend on the length is just weird.

The patch for this endeavor is:

diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -1306,7 +1306,7 @@ describeOneTableDetails(const char *schemaname,
        printTableAddHeader(&cont, headers[i], true, 'l');

    /* Check if table is a view */
-   if (tableinfo.relkind == 'v')
+   if (tableinfo.relkind == 'v' && verbose)
    {
        PGresult   *result;

Any final words?

diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -1306,7 +1306,7 @@ describeOneTableDetails(const char *schemaname,
printTableAddHeader(&cont, headers[i], true, 'l');

/* Check if table is a view */
-   if (tableinfo.relkind == 'v')
+   if (tableinfo.relkind == 'v' && verbose)
{
PGresult   *result;

Any final words?

Thanks?

--Josh Berkus