Re: Review: query result history in psql - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Review: query result history in psql
Date
Msg-id 51D72A83.7040201@agliodbs.com
Whole thread Raw
In response to Review: query result history in psql  (ian link <ian@ilink.io>)
List 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 by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Eliminating PD_ALL_VISIBLE, take 2
Next
From: Tom Lane
Date:
Subject: Re: Millisecond-precision connect_timeout for libpq