Re: Show type in psql SELECT - Mailing list pgsql-hackers

From David Fetter
Subject Re: Show type in psql SELECT
Date
Msg-id 20130224005834.GB2277@fetter.org
Whole thread Raw
In response to Re: Show type in psql SELECT  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Show type in psql SELECT  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Sat, Feb 23, 2013 at 12:07:35PM -0800, Jeff Janes wrote:
> On Sat, Feb 23, 2013 at 9:55 AM, David Fetter <david@fetter.org> wrote:
> > On Sat, Feb 23, 2013 at 12:09:51PM +1300, Mike Toews wrote:
> > > Hi hackers,
> > >
> > > Type info can be viewed with "\d mytable", however often I'd
> > > like to see the type (and typmod) info in SELECT queries with
> > > psql, similar to pgAdmin III. For example:
> >
> > I'm thinking we should add it as a SET parameter and expose it to
> > all SQL.
> 
> This information is already provided through libpq, see PQftype.

Not everyone uses libpq, so my argument for making it available at the
SQL level stands.

> It is merely a matter of making psql present the data it already has
> in a way people find convenient.

With utmost respect for your talent and contributions, what you're
calling, "merely," here is one of the main barriers to PostgreSQL
adoption.  It's our attitude--fortunately not the dominant one--that
if it's available through some API, however obscure or complicated,
our job is done.

That may have been so in 2001, but even then we were getting our rear
ends handed to us by an outfit that, despite its massive technical
inferiority, took end-user usability very carefully into account.

The way I look at it, easy things should be easy, and this is an easy
thing.

> > The next client program(s) shouldn't have to re-invent this
> > separately.
> 
> The client has to decide what to do with this information, I don't
> see any way around that.  The server can't make that decision for
> it.

I don't know how you got the idea that the server should decide this
from what I wrote.  What I suggested was that we make this
available--not mandatory or auto-detected--via the SQL API, namely
with a SET command.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@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



pgsql-hackers by date:

Previous
From: Jov
Date:
Subject: Re: make: *** pg_xlogdump: No such file or directory. Stop.
Next
From: Jov
Date:
Subject: Re: ERROR: invalid option "use_remote_estimate"