>Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> You think that the users of the libpq() interface (or even the
> protocol itself) are going to handle getting \dt-type output back
> somehow..?
If you look back in the thread, you'll see that I admitted my
ignorance of whether this could be properly implemented in the back
end without a protocol change. Ignorance being bliss, I can revel
in the dreams of *having* such a feature without being dragged down
by the potential pain of its implementation. ;-)
I know, though, that the JDBC spec supports such things -- you can
keep pulling ResultSet objects off the wire, each with its own
distinct set of columns. (That is, each ResultSet has its own
ResultSetMetaData which specifies how many columns that particular
ResultSet has, what the column names are, what the data type is for
each column, etc. Each ResultSet returned from a response stream
for a request can be entirely different in all of these
characteristics.)
> As what, a single-column result of type text?
No, that would be horrible. That has been mentioned as a
possibility, and it makes me shudder.
> And then they'll use non-fixed-width fonts, undoubtably, which
> means the results will end up looking rather ugly, even if we put
> in the effort to format the results.
With, for example, Sybase's sp_help, each result set can be listed
any way the client chooses -- I've seen it put into character format
like the psql \d commands, I've seen each result set put into a
table for brower-based query tools, and I've seen each result set
put into a JTable for Java Swing applications. If a client gets
back a series of result sets, the sky is the limit.
-Kevin