SHOW TABLES
in [PgSql]
|
From: "Greg Sabino Mullane" on 19 Jul 2010 10:31 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Kevin Grittner wrote: > Any solution which only works within psql isn't a solution for a > large part of the problem space people are trying to address. One > important goal is that if someone spends a day to whip up a GUI > query tool (as I did when I first started working in Java), it's > easy to get displays like we get from the psql backslash commands > (as it was in Sybase, which is what we were using at the time, > through sp_help and related stored procedures). I don't agree that this is an important goal. Certainly someone writing a GUI (or a new driver) should be expected to be familiar with the system catalogs. Moreover, a GUI relies on an underlying driver, and every driver should already be providing things like a list of tables natively. - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201007191030 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkxEYZ0ACgkQvJuQZxSWSsiIlQCfdXDgTqletVez/r+pKHY4EcW6 QAsAoPLUmblzN2aNEw5DveHEav3XyB/K =TGq1 -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 19 Jul 2010 10:31 >Stephen Frost <sfrost(a)snowman.net> wrote: > You think that the users of the libpq() interface (or even the > protocol itself) are going to handle getting \dt-type output back > somehow..? If you look back in the thread, you'll see that I admitted my ignorance of whether this could be properly implemented in the back end without a protocol change. Ignorance being bliss, I can revel in the dreams of *having* such a feature without being dragged down by the potential pain of its implementation. ;-) I know, though, that the JDBC spec supports such things -- you can keep pulling ResultSet objects off the wire, each with its own distinct set of columns. (That is, each ResultSet has its own ResultSetMetaData which specifies how many columns that particular ResultSet has, what the column names are, what the data type is for each column, etc. Each ResultSet returned from a response stream for a request can be entirely different in all of these characteristics.) > As what, a single-column result of type text? No, that would be horrible. That has been mentioned as a possibility, and it makes me shudder. > And then they'll use non-fixed-width fonts, undoubtably, which > means the results will end up looking rather ugly, even if we put > in the effort to format the results. With, for example, Sybase's sp_help, each result set can be listed any way the client chooses -- I've seen it put into character format like the psql \d commands, I've seen each result set put into a table for brower-based query tools, and I've seen each result set put into a JTable for Java Swing applications. If a client gets back a series of result sets, the sky is the limit. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 19 Jul 2010 10:52 * Kevin Grittner (Kevin.Grittner(a)wicourts.gov) wrote: > I know, though, that the JDBC spec supports such things -- you can > keep pulling ResultSet objects off the wire, each with its own > distinct set of columns. (That is, each ResultSet has its own > ResultSetMetaData which specifies how many columns that particular > ResultSet has, what the column names are, what the data type is for > each column, etc. Each ResultSet returned from a response stream > for a request can be entirely different in all of these > characteristics.) I'm pretty sure we don't have the ability to support that at either the libpq or the protocol level today, but in general I do think it's a good idea and would be good to support. To be honest, I seem to recall someone talking about working on it (or perhaps it's on the TODO?). In any case, long way there from here. Thanks, Stephen
From: Robert Haas on 19 Jul 2010 10:54 On Mon, Jul 19, 2010 at 10:25 AM, Greg Sabino Mullane <greg(a)turnstep.com> wrote: >> in the "alphabet soup" paragraph above. �I don't think there's >> anything WRONG with letting "\dFp" show text search dictionaries and >> "\dfwS+" list system window functions with additional detail - but I'd >> like an alternative that emphasizes ease of remembering over brevity, >> works in every client, and can be extended in whatever reasonable ways >> the community decides are worth having. > ... > I don't know that I'd necessarily remember all those any better, and would > certainly not enjoy typing out: > > LIST TEST SEARCH DICTIONARIES > > I don't have to remember \dFp - all I have to remember is \?. For the > more common ones that I use day to day and don't have to look up > (\d \dt \df \l etc.) the advantage of a two or three character > string is strong. I don't think anyone is proposing getting rid of backslash commands. That would be nuts. What's being proposed is to try to create a better way to list objects, a way that involves some server-side support so that clients don't need to muck about with system catalogs quite so much. I like psql as well as anyone, but saying that it's easy to do this stuff because you can use \? to get the appropriate backslash command seems to me to be missing the point. Suppose you regularly use PGadmin to access the database, or some other graphical client, and you want to find a query to list the comments on every item in the database. Good luck! You'll need to figure out how to use psql, discover that it has a -E switch (of which I was ignorant for my first 10 years of using PostgreSQL), and get the query out of there. Then you'll find that the query psql uses is more than 50 lines long and also wrong: it omits half the object types. Woohoo! And even supposing that you fix the query, there's no guarantee that it won't be wrong again when PG version X+1 comes out. Take a look at describe.c. It's riddled with special cases for particular PG versions, special cases that must be replicated in every other client that wants to work with multiple PG versions. So, basically, our advice to anyone who wants a simple, portable way to list objects of particular types in a cross-PG version compatible way is - copy the logic in describe.c, adapt it to your application, and update it every time a new major release comes out. Is that really the best we can do, and do we really think that's adequate? >> being powerful rings totally hollow for me. �For ordinary, day to day >> tasks like listing all my tables, or looking at the details of a >> particular table, they're great. �I use them all the time and would >> still use them even if some other syntax were available. �But there is >> no reasonable way to pass options to them, and that to me is a pretty >> major drawback. > > Well, there's the rub. You're arguing this from a hacker's persepective, > while the SHOW syntax seems to be overwhelmingly agreed upon to be either > helpful for clueless noobs, or some nice syntactic sugar for average users. I use the darn database, too. The machinations I've gone through to get some of the information are ridiculously complex. As Larry Wall one said, a good programming language should make simple things simple and complicated things possible; so, I don't believe that having a simple interface and a powerful interface are mutually exclusive goals. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 19 Jul 2010 13:23
On Mon, Jul 19, 2010 at 02:12:19PM -0000, Greg Sabino Mullane wrote: > > -----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. It covers 0% of cases where people are not using psql. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |