Re: Review: query result history in psql

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Review: query result history in psql
Дата
Msg-id 51D72A83.7040201@agliodbs.com
обсуждение исходный текст
Ответ на Review: query result history in psql  (ian link <ian@ilink.io>)
Список pgsql-hackers
On 07/02/2013 06:16 PM, Robert Haas wrote:
> I'm kinda not all that convinced that this feature does anything
> that's actually useful.  If you want to save your query results, you
> can just stick "CREATE TEMP TABLE ans AS" in front of your query.
> What does that not give you that this gives you?

Convenience.  Think of the times when you were doing a "quick check" on
some query result from several different queries and wanted to flip back
and forth between them, but you can't do that by scrolling because the
pager has the query result and hides it from terminal scrolling.  If we
had this feature, I'd use it a lot, personally.

My take on the issues discussed:

Interactive Mode: I personally don't see value in this, and wouldn't use
it if it existed.  Plus even if there is value in it, it could be added
later on, so shouldn't block this patch.

Finding Query Results: I don't find the approach of "ans01/ans02/ans03"
useful.  For any place where I really need this feature, I'm going to
have enough buffered queries that there's no way I can remember which is
which.  I don't, however, have an immediate solution for something which
would be overall easier.  Maybe a prompt after each query for what name
to put it in the history as?  Not sure.

"ans": I agree that this is not intuitive for most DBAs.  The other
applications which use that abbreviation do not have sufficient overlap
with PostgreSQL for it to be natural.  What about just "result"?

Size Limits: before this becomes a PostgreSQL feature, we really do need
to have some limits, both for total memory size, and for number of saved
query result sets.  Otherwise we'll have lots of people crashing their
clients because they forgot that result history was on.

Also, I'd like to think some about how this could, potentially, in the
future tie in to being able to dispatch asyncronous queries from psql.
If we have a query result cache, it's one short step to allowing that
result cache to be populated asyncrhonously.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Eliminating PD_ALL_VISIBLE, take 2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Millisecond-precision connect_timeout for libpq