SHOW TABLES
in [PgSql]
|
From: Robert Haas on 15 Jul 2010 21:57 On Thu, Jul 15, 2010 at 5:34 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2010-07-15 at 13:44 -0500, Robert Haas wrote: >> Sounds good, but we need agreement on a more detailed design first. > What do you mean? Exactly which commands are we going to support? With exactly what syntax? What information will be returned by each command? In what format? We have no agreement on any of these points. I am of the view that this is not worth doing if it is only a kludge to make things sort-of work for newbies, with the expectation that they'll never do it again once they learn how to use backslash commands (and let's keep in mind that many users access the database through tools other than psql - e.g. pgadmin). I am also of the view that it would be poor to have allow users to type "show tables" to see tables and "show functions" to see functions but require them to type "\des" to see foreign servers. That's not a real fix for any real problem - that's a cheap hack. If we can create a command set which is (1) more mnemonic than the existing backslash commands, (2) generates tabular output that can easily be used by scripts and clients other than psql, (3) applies across-the-board to all of our object types, and (4) is capable of providing all the same functionality that we currently get through "\d<whatever>" commands, then I'm in favor of it. Otherwise, I'm probably not, though I'm willing to listen to what you and others have to say. It's possible that the community might be in favor of a solution which doesn't include all of the above elements, but you can't presume that because the community is generally in favor of doing something along the lines that they will also be in favor of any specific proposal. That's why I think it's important to have, and agree on, a detailed design before writing code. -- 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: "Marc G. Fournier" on 15 Jul 2010 23:27 On Thu, 15 Jul 2010, Simon Riggs wrote: > On Thu, 2010-07-15 at 13:44 -0500, Robert Haas wrote: >> That seems rather wretched for machine-parsability, which I think is >> an important property for anything we do in this area. > > I completely disagree. This is for humans only, and mostly newbies only. > > Anybody that wants structured output can type the SQL and get as much > structure as they want. I'm not reinventing the whole wheel. 'k, but now we are back to why can't this just be an extension of psql vs in the backend? If someone writing an interface should be typing the SQL to get the information, then 'SHOW TABLES' doesn't really provide them anything, does it? ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy(a)hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy(a)hub.org -- 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: Josh Berkus on 16 Jul 2010 00:18 All, So, from my perspective is that the main issue with the \d commands is that they are not accessible from interfaces other than psql. Often, you have to write a big, hairy, pg-version-specific query to make them happen. information_schema is nice but (a) it's not in the default search path, and (b) it doesn't show everything. Just try to get your list of FKs out of it. Think of the number of people who use "echo commands" just to extract the query for the \d commands. This was why we (well, mainly Andrew Geirth) developed newsysviews. But you know how that went. I think that users could live with other syntax (like SELECT name FROM pg_tables()) if the result returned were intuitive (user tables only) and didn't change over postgres versions much. As Andrew points out, SQLServer users seem to have no problem calling sp_* commands. I think it's very important, as Haas says, to consider that whatever we do in this arena, we'll be living with it forever, so let's not make the \dv vs. \df mistake again, ok? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- 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: =?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= on 16 Jul 2010 03:45 On Jul 15, 2010, at 6:43 PM, Magnus Hagander wrote: > On Thu, Jul 15, 2010 at 18:35, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: >> >>> Is there an actual common use-case for having these commands available >>> for *non-psql* interfaces? >> >> There are many interfaces out there and people writing new ones >> everyday. We just wrote an interface for Android, for example. >> >> It is arguably *more* important to do this from non-psql interfaces. >> >> There should be one command to "display a list of tables" and it needs >> to be easily guessable for those who have forgotten. > > The downside is that you are then limited to what can be returned as a > resultset. A "\d table" in psql returns a hell of a lot more than > that. So do we keep two separate formats for this? Or do we remove the > current, useful, output format in favor of a much worse formt just to > support more clients? > i am not seeing this as an "instead" solution. this is an "additional" solution. SHOW TABLES etc could return a set of table. there is not need to change good of \d for that. it just a plain add on. everything else would be simply bad. many thanks, hans -- Cybertec Sch�nig & Sch�nig GmbH Gr�hrm�hlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- 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: Simon Riggs on 16 Jul 2010 11:11
On Fri, 2010-07-16 at 14:07 +0100, Thom Brown wrote: > The problem is people are stating different requirements. > > - to make it easy for new users of psql > - to simplify fetching basic database information from any client application > - to ease transition between MySQL and PostgreSQL Close, but I didn't state any of those as you have them. I want to make it easy for newbies to get access to obvious things like a list of tables, from *any* interactive application, wherever they exist. There are many and various apps and not all of them work the same. (The Windows installer ships two, for example). It would be nice to tell people "just type SHOW TABLES" and have it be true 100% of the time. They can remember that, or at least will try it if they can't remember anything at all about our RDBMS. Not trying to ease the transition between MySQL and PostgreSQL, it is about making things obvious for overworked sysadmins and DBAs. Many people are familiar with MySQL and many people use both. There are also dozens of legacy RDBMS for DBAs to remember: Sybase, DB2, Informix, Teradata, Ingres, MySQL and many others. Providing obvious commands that help people who have never connected or only connect sporadically would do much to help our cause. We are widely regarded as unhelpful, "difficult to get started" etc.. If we had a dollar for every person that has shouted "OMG what is the damn command on Postgres?" it would easily fund this development. This is not about simplifying things. It is about being obvious. Light switches are usually at shoulder height next to a door. Our light switches are 2 metres up, on the far side of the room. People are sick of banging their knees on furniture while trying to grope for the light. The light switch isn't so much hard to use, its just in the wrong place. We must envisage what it is to be a person that doesn't know where the switch is, or have forgotten. We don't need a programmable light switch API, or a multi-function light remote control. Just a switch by all of the doors. (Oh, they're probably not called lights outside UK; room lamps maybe?) -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |