Re: SHOW TABLES

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SHOW TABLES
Date: 2010-07-19 14:12:19
Message-ID: 759d21511cbea7f6d3511d55a6aeb8f2@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> 1. \d isn't exactly the most intuitive thing ever
>

Seems fairly mnemomic to me (d=describe) and it packs a
*lot* of information into a single letter (see below).
Things that are done often should have short keystrokes,
and not require learning Yet Another Meta-Language.

> And it's pretty clear that we have been heading into some
> increasingly cryptic bits of fruit salad of
> \dfzb+-meta-bucky-alt-foo

No arguments there, but that's the nature of the beast. I don't
think it's as bad as is made out, however, as \d covers 99% of
everyday usage and certainly the "show tables" that started
this thread.

> Having SHOW THIS and SHOW THAT which are a bit more readily
> guessed would be somewhat nice.

I'm not sure why "easily guessed" is thrown out in this thread as
such a great thing. To achieve that goal, we simply need the
help system that has been proposed many times: entering in
"SHOW <anything>" gives you a quick rundown of the backslash system.

As far as SHOW THIS, there is a big difference from a plain "\dt"
and "\d <tablename>". The former could be emulated quite easily
with a SHOW command (although even our \dt prints out more information
than mysql's SHOW TABLES), but the latter includes a crazy amount
of information that would lead to quite a large "SHOW..." statement.
Also, if it were made a server-side thing, how would you return things
like indexes on a table in a SRF? Have a meta-column describing what
the other columns represent? Ugly.

> information_schema doesn't have some useful things that we'd like
> ait to have
...
> Alas, I don't see a good way to improve on this :-(

newsysviews seems the way out of that particular mess. I'm also not
particularly opposed to adding new views or columns to
information_schema. We would still support the standard by
having all the required views and columns.

> The \? commands are *solely* for psql, and it would be nice to
> have the Improvement work on server side so it's not only usable
> with the one client.

Agreed, but is there some other command-line client? If it's not
command-line, free-form SQL typing, it inevitably already has
support for querying the catalogs built in. At least, every GUI,
app, and driver I can think of does.

> I've seen too many QA scripts that do awk parsing of output of
> psql "\d" commands that are vulnerable to all kinds of awfulness.

They should be querying information_schema.

> I'd sure like to be able to write queries that *don't* involve
> array smashing or using "grep" on \z output to analyze object
> permissions.

Yeah, that would be a better information_schema. :)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201007191011
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxEXS0ACgkQvJuQZxSWSshLKwCffkfe0T3tELInxRqG7yCDS5Vr
Ku8AoLUtOu7tTplGZZLPOEuDfKHt+EEm
=Oubu
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew Wakeling 2010-07-19 14:16:12 Re: Trouble with COPY IN
Previous Message Matthew Wakeling 2010-07-19 14:11:06 Re: Trouble with COPY IN