From: "Joshua D. Drake" on
On Thu, 2010-07-15 at 18:02 +0200, Guillaume Lelarge wrote:

> > I have to agree with Simon here. \d is ridiculous for the common user.
> >
> > SHOW TABLES, SHOW COLUMNS makes a lot of sense. Just has something like
> > DESCRIBE TABLE foo makes a lot more sense than \d.
> >
>
> And would you add the complete syntax? I mean:
>
> SHOW [OPEN] TABLES [FROM db_name] [LIKE 'pattern']
>
> I'm wondering what one can do with the [FROM db_name] clause :)

Well I hadn't thought it out fully. I was just shutting down somebody
elses idea that the feature had no legs. Which is obviously, not true.

Let the discussion bloom :D

JD

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering


--
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
On Thu, 15 Jul 2010, Thom Brown wrote:

> If it's only a psql problem, why implement it as SQL? Is it just so
> we're not adding keywords specifically to psql? In that case, it
> shouldn't support QUIT.

Personally, I think this is somethign that should go into the backend ...
I'd like to be able to write perl scripts that talk to the backend without
having to remember all the various system tables I need to query / join to
get the same results as \d gives me in psql ... same for any interface
language, really ...

----
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: Thom Brown on
On 15 July 2010 17:07, Marc G. Fournier <scrappy(a)hub.org> wrote:
> On Thu, 15 Jul 2010, Thom Brown wrote:
>
>> If it's only a psql problem, why implement it as SQL? �Is it just so we're
>> not adding keywords specifically to psql? �In that case, it shouldn't
>> support QUIT.
>
> Personally, I think this is somethign that should go into the backend ...
> I'd like to be able to write perl scripts that talk to the backend without
> having to remember all the various system tables I need to query / join to
> get the same results as \d gives me in psql ... same for any interface
> language, really ...
>

Isn't that what the information_schema catalog is for?

Thom

--
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
On Jul 15, 2010, at 10:50 AM, "Joshua D. Drake" <jd(a)commandprompt.com> wrote:
> On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote:
>
>>> Looks like the last time this was discussed, there wasn't any clear
>>> conclusion. Someone created a patch and it's still on the TODO list:
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php
>>
>> That one is about:
>> a) doing it in psql., not the backend
>> b) not actually implementing the command, but implementing hints for
>> the user telling them which is the correct command
>>
>> Is there an actual common use-case for having these commands available
>> for *non-psql* interfaces?
>
> Yes. We should provide a single, well described grammar for interacting
> with objects in the database regardless of client. I should be able to
> open ANY SQL terminal, and type SHOW ME THE MONEY and have Benjamins
> fall out.

Damn straight. I like \d as well as anyone but there are real problems with it. Perhaps when we add \dxrvbfqS$: we'll stop to reflect on what they are.

Having said that, I want to urge that we spend a suitable amount of time and thought and care designing this, lest it turn into a mess. I have no interest in slamming something through without adequate consideration.

....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: "Marc G. Fournier" on
On Thu, 15 Jul 2010, Thom Brown wrote:

> On 15 July 2010 17:07, Marc G. Fournier <scrappy(a)hub.org> wrote:
>> On Thu, 15 Jul 2010, Thom Brown wrote:
>>
>>> If it's only a psql problem, why implement it as SQL? �Is it just so we're
>>> not adding keywords specifically to psql? �In that case, it shouldn't
>>> support QUIT.
>>
>> Personally, I think this is somethign that should go into the backend ...
>> I'd like to be able to write perl scripts that talk to the backend without
>> having to remember all the various system tables I need to query / join to
>> get the same results as \d gives me in psql ... same for any interface
>> language, really ...
>>
>
> Isn't that what the information_schema catalog is for?

I'd rather write:

SHOW TABLES;

then:

SELECT table_name
FROM information_schema.tables
WHERE table_type = 'BASE TABLE'
AND table_schema NOT IN
('pg_catalog', 'information_schema');

And, the latter, unless I'm doing it regularly, is alot harder to remember
then the former ...


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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Prev: [HACKERS] SHOW TABLES
Next: reducing NUMERIC size for 9.1