Re: Show type in psql SELECT

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: Show type in psql SELECT
Дата
Msg-id 20130224005834.GB2277@fetter.org
обсуждение исходный текст
Ответ на Re: Show type in psql SELECT  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Show type in psql SELECT  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Jov
Дата:
Сообщение: Re: make: *** pg_xlogdump: No such file or directory. Stop.
Следующее
От: Jov
Дата:
Сообщение: Re: ERROR: invalid option "use_remote_estimate"