Re: SHOW TABLES - Mailing list pgsql-hackers

From Richard Huxton
Subject Re: SHOW TABLES
Date
Msg-id 4C3F60DA.3080506@archonet.com
Whole thread Raw
In response to Re: SHOW TABLES  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: SHOW TABLES
Re: SHOW TABLES
List pgsql-hackers
On 15/07/10 19:44, Robert Haas wrote:
> On Jul 15, 2010, at 11:59 AM, Simon Riggs<simon@2ndQuadrant.com>
> wrote:
>>
>> I imagined that we would do something similar to EXPLAIN, a set of
>> text rows returned.
>
> That seems rather wretched for machine-parsability, which I think is
> an important property for anything we do in this area.  We need to
> think harder about how we could structure this to allow returning
> more than just a tabular result set while still allowing clients easy
> programmatic access to the underlying data.
>
>> It should be possible to migrate \d options to using new outputs,
>> when everything works in a useful manner. Probably not in this
>> release.

Feature sounds useful. I think our \dxx commands have grown a little
unwieldy in the last version or two. Which is not to say you can take \d 
away :-)

I was assuming the process would be something like:
1. Move existing \d queries into functions*
2. Convert psql to use those
3. Add "SHOW xxx" and have it return a single query   Have it also issue "NOTICE: from psql, try \dt for more info"

If/when we have multiple sets returned from one query it should be 
simple to provide something pretty close to \d... from a single command.

Trying to format the data in the backend is probably just going to 
frustrate writers of different clients (of which I think we have quite a 
few now).

* These functions could then be back-ported as an admin-pack too for 
clients/apps that wanted cross-version compatibility for these sorts of 
things.

--   Richard Huxton  Archonet Ltd


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: SHOW TABLES
Next
From: Andreas 'ads' Scherbaum
Date:
Subject: Re: SHOW TABLES