Re: SHOW TABLES

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: SHOW TABLES
Дата
Msg-id AANLkTim=GMmLxQZSqSbw3QEfSSAbFbng4=LRQAvN6NE4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SHOW TABLES  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-hackers
On Mon, Jul 19, 2010 at 10:25 AM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>> in the "alphabet soup" paragraph above.  I don't think there's
>> anything WRONG with letting "\dFp" show text search dictionaries and
>> "\dfwS+" list system window functions with additional detail - but I'd
>> like an alternative that emphasizes ease of remembering over brevity,
>> works in every client, and can be extended in whatever reasonable ways
>> the community decides are worth having.
> ...
> I don't know that I'd necessarily remember all those any better, and would
> certainly not enjoy typing out:
>
> LIST TEST SEARCH DICTIONARIES
>
> I don't have to remember \dFp - all I have to remember is \?. For the
> more common ones that I use day to day and don't have to look up
> (\d \dt \df \l etc.) the advantage of a two or three character
> string is strong.

I don't think anyone is proposing getting rid of backslash commands.
That would be nuts.  What's being proposed is to try to create a
better way to list objects, a way that involves some server-side
support so that clients don't need to muck about with system catalogs
quite so much.

I like psql as well as anyone, but saying that it's easy to do this
stuff because you can use \? to get the appropriate backslash command
seems to me to be missing the point.  Suppose you regularly use
PGadmin to access the database, or some other graphical client, and
you want to find a query to list the comments on every item in the
database.  Good luck!  You'll need to figure out how to use psql,
discover that it has a -E switch (of which I was ignorant for my first
10 years of using PostgreSQL), and get the query out of there.  Then
you'll find that the query psql uses is more than 50 lines long and
also wrong: it omits half the object types.  Woohoo!

And even supposing that you fix the query, there's no guarantee that
it won't be wrong again when PG version X+1 comes out.  Take a look at
describe.c.  It's riddled with special cases for particular PG
versions, special cases that must be replicated in every other client
that wants to work with multiple PG versions.  So, basically, our
advice to anyone who wants a simple, portable way to list objects of
particular types in a cross-PG version compatible way is - copy the
logic in describe.c, adapt it to your application, and update it every
time a new major release comes out.  Is that really the best we can
do, and do we really think that's adequate?

>> being powerful rings totally hollow for me.  For ordinary, day to day
>> tasks like listing all my tables, or looking at the details of a
>> particular table, they're great.  I use them all the time and would
>> still use them even if some other syntax were available.  But there is
>> no reasonable way to pass options to them, and that to me is a pretty
>> major drawback.
>
> Well, there's the rub. You're arguing this from a hacker's persepective,
> while the SHOW syntax seems to be overwhelmingly agreed upon to be either
> helpful for clueless noobs, or some nice syntactic sugar for average users.

I use the darn database, too.  The machinations I've gone through to
get some of the information are ridiculously complex.  As Larry Wall
one said, a good programming language should make simple things simple
and complicated things possible; so, I don't believe that having a
simple interface and a powerful interface are mutually exclusive
goals.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: SHOW TABLES
Следующее
От: Robert Haas
Дата:
Сообщение: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock