SHOW TABLES
in [PgSql]
|
From: Robert Haas on 16 Jul 2010 07:56 On Jul 15, 2010, at 11:18 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > 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? Refresh my memory? ....Robert -- 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: Robert Haas on 16 Jul 2010 12:56 On Jul 16, 2010, at 7:43 AM, Bruce Momjian <bruce(a)momjian.us> wrote: > Andrew Dunstan wrote: >> >> Bruce Momjian wrote: >>> I assume SHOW TABLES would only be useful for interactive terminal >>> sesssions, not for application code (which should use >>> information_schema), so what non-psql interactive terminal programs are >>> there? >>> >>> >> >> I think your assumption is questionable. >> >> Plenty of people use MySQL's "SHOW TABLES" in non-interactive settings >> (for good or ill). That's why any suggestion that we should return >> anything other than a resultset seems like a really terrible idea to me. > > If they are writing an application, finding the query to show all tables > is the least of their problems. I don't see how SHOW TABLE > significantly helps in that case, except make things 0.001% easier, > while creating duplicate functionality in Postgres. Many years ago I needed to write a program that needed to be able to fetch a list of tables in the DB, and then a list of attributes for each table. It took me at least a full day and I almost gave up and abandoned PostgreSQL as a result. I think calling this duplicate functionality is ridiculous. Sure, it's possible. In fact, it's very easy. For committers. ....Robert -- 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: Rob Wultsch on 16 Jul 2010 13:11 On Fri, Jul 16, 2010 at 9:56 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: > For committers. Perhaps this discussions should be moved to the General list in order to poll the userbase. My .02 is that SHOW commands (even if they are not compatible) would make it much easier for me to make an argument to my boss to at least consider moving off another open source database. The show commands are in *very* widespread use by the MySQL community even after ~5 years of having the i_s. The Drizzle team (a radical fork of MySQL) very briefly considered removing the SHOW commands and the unanimous objections that followed caused that idea to scrapped. -- Rob Wultsch wultsch(a)gmail.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: "Marc G. Fournier" on 16 Jul 2010 13:13 On Fri, 16 Jul 2010, Simon Riggs wrote: > SQLServer and Sybase use sp_ procedures for this Haven't experienced Sybase for 2 years in my last job, I can tell you that the sp_* commands are definitely non-intuitive :( ---- 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: "Kevin Grittner" on 16 Jul 2010 13:31
"Marc G. Fournier" <scrappy(a)hub.org> wrote: > Haven't experienced Sybase for 2 years in my last job, I can tell > you that the sp_* commands are definitely non-intuitive :( In general, I'd agree; although I think I got used to them about as fast as the PostgreSQL backslash commands. In the particular case of sp_help I would disagree; once you've heard that, it's pretty easy to remember and it works for tables, views, stored procedures, logs, rules, defaults, triggers, referential constraints, encryption keys, and check constraints. You type: sp_help <pretty-much-any-database-object> And you get information back which is both reasonably human-digestable based on the formatting of result sets in whatever client you're using, and reasonably machine-digestable based on looking at the column headers of the result sets. -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 |