Re: SHOW TABLES

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>
Cc: "Thom Brown" <thombrown(at)gmail(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: SHOW TABLES
Date: 2010-07-15 16:51:46
Message-ID: 4C3EF652020000250003364F@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> wrote:

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

The solution to this on some products (e.g., Sybase ASE) is to embed
such logic in stored procedures. A stored procedure can generate an
intermingled stream of results sets with different layouts and INFO,
WARN, etc. lines. If we *had* stored procedures with such
capabilities, I think that would be the direction to go; since we
don't, I'm ambivalent.

I don't suppose a stored procedure implementation is in the works
anywhere?

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-07-15 16:55:05 Re: SHOW TABLES
Previous Message Simon Riggs 2010-07-15 16:48:12 Re: SHOW TABLES