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