From: "Joshua D. Drake" on
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

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