On Jul 15, 2010, at 11:59 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Thu, 2010-07-15 at 18:43 +0200, Magnus Hagander wrote: >> On Thu, Jul 15, 2010 at 18:35, Simon Riggs <si...@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 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. > > If I get some working solutions ready for Sept 15 we then have 4 months > for other people to patch away at this. Sounds good, but we need agreement on a more detailed design first. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
