From: "Joshua D. Drake" on 19 Jul 2010 13:31 On Mon, 2010-07-19 at 10:23 -0700, David Fetter wrote: > On Mon, Jul 19, 2010 at 02:12:19PM -0000, Greg Sabino Mullane wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: RIPEMD160 > > > > > > > 1. \d isn't exactly the most intuitive thing ever > > > > Seems fairly mnemomic to me (d=describe) and it packs a > > *lot* of information into a single letter (see below). > > Things that are done often should have short keystrokes, > > and not require learning Yet Another Meta-Language. > > > > > And it's pretty clear that we have been heading into some > > > increasingly cryptic bits of fruit salad of > > > \dfzb+-meta-bucky-alt-foo > > > > No arguments there, but that's the nature of the beast. I don't > > think it's as bad as is made out, however, as \d covers 99% of > > everyday usage and certainly the "show tables" that started > > this thread. > > It covers 0% of cases where people are not using psql. Which is probably 85% of our users. (No I have no actual metric) Every single corp I have walked into is using at least PgAdmin as well. Until this project as a whole recognizes that for the majority to the populace the command line is dead; we will continue to have these arguments for no apparent reason but to make sure spam filters are still reading our emails. 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: "Greg Sabino Mullane" on 19 Jul 2010 13:47 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 David Fetter wrote: >> No arguments there, but that's the nature of the beast. I don't >> think it's as bad as is made out, however, as \d covers 99% of >> everyday usage and certainly the "show tables" that started >> this thread. > It covers 0% of cases where people are not using psql. Yes, and everything else already has a "show tables". See for example, PPA: http://phppgadmin.sourceforge.net/images/4.png - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201007191342 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkxEj4kACgkQvJuQZxSWSshrwgCg65eIziE2SW8XhdTSHwVMzxnm ynIAoLPOc0yuKyrE2kaaJFq5UiDb45Nd =veva -----END PGP SIGNATURE----- -- 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: David Fetter on 19 Jul 2010 14:09 On Mon, Jul 19, 2010 at 09:31:06AM -0500, Kevin Grittner wrote: > >Stephen Frost <sfrost(a)snowman.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.) Would something like this do? Thanks to Andrew Gierth for helping me figure out how to get this working :) CREATE OR REPLACE FUNCTION multi_result() RETURNS SETOF REFCURSOR LANGUAGE plpgsql AS $$ DECLARE r RECORD; ref REFCURSOR; BEGIN FOR r IN SELECT table_name FROM information_schema.tables WHERE table_schema = 'information_schema' LOOP ref := 'multi_result_' || quote_ident(r.table_name); OPEN ref FOR EXECUTE 'SELECT * FROM information_schema.' || quote_ident(r.table_name); /* Not really needed. */ RETURN NEXT ref; ref := NULL; END LOOP; RETURN; END; $$; BEGIN; SELECT * FROM multi_result(); FETCH FORWARD ALL FROM multi_result_views; ROLLBACK; > > As what, a single-column result of type text? > > No, that would be horrible. That has been mentioned as a +1 on the shuddering. Add also nausea. :P > > 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. Ad astra per PostgreSQL! Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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: "Kevin Grittner" on 19 Jul 2010 18:16
David Fetter <david(a)fetter.org> wrote: > Would something like this do? Thanks to Andrew Gierth for helping > me figure out how to get this working :) > > CREATE OR REPLACE FUNCTION multi_result() > RETURNS SETOF REFCURSOR With appropriate tweaks to JDBC and the other drivers, this would cover a lot of ground. You might be able to cover the last little bit by returning a SETOF some record with (at least) three columns, one of which would be filled in each row: REFCURSOR (for a result set), INTEGER (for a row count), and something which could carry an object which would map to a SQLWarning (which can be used with SQLSTATE '00000' to deliver informational text or '01xxx' for actual warnings). A JDBC execute request (as opposed to executeUpdate or executeQuery) may get back any combination of the above in an ordered fashion. Essentially, this meta result set would need to be hidden within the Statement object. http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/sql/Statement.html#execute%28java.lang.String%29 http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/sql/Statement.html#getWarnings%28%29 -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |