Skip site navigation (1) Skip section navigation (2)

Re: SHOW TABLES

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Thom Brown <thombrown(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SHOW TABLES
Date: 2010-07-16 01:57:44
Message-ID: AANLkTim-1VRAWLJNEKP82P+Tko2mstwXcP336B6KWe-t@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jul 15, 2010 at 5:34 PM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-07-16 02:25:09
Subject: Re: dividing money by money
Previous:From: Tom LaneDate: 2010-07-16 00:46:22
Subject: Re: small exclusion constraints patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group