Re: Review: query result history in psql

Maciej - I can see your resistance to some kind of interactive mode. It
would definitely be more code and create a less simple user interface. I
would be perfectly happy if we left that part as it is now.

However, I think it would be important to have a way of displaying the
query history. Yes, you can search through your console backwards. You
can still search through your old queries, but this would be a good
alternative. What if the user reconnects after working for a while?
Their old bash history might be gone. This would leave them with a big
query history and no point of reference. Personally, I would find this
feature very worthwhile. The query history wouldn't be crippled without
it, but it would be a lot less flexible.

> Pavel Stehule <mailto:pavel(dot)stehule(at)gmail(dot)com>
> Monday, July 01, 2013 4:05 AM
>
> a idea is good, but I don't think, it can be useful with current
> implementation. How I can identify, what is correct answer for my
> query? Have I remember twenty numbers and twenty queries?
>
> Regards
>
> Pavel
>
>
> Maciej Gajewski <mailto:maciej(dot)gajewski0(at)gmail(dot)com>
> Monday, July 01, 2013 4:01 AM
>
> When I tested this feature, I had 30 caches per 5 minutes, and only a
> few from these queries had a sense. Switch between off and on is not
> user friendly. I believe so there can be other solution than mine, but
> a possibility to friendly clean unwanted caches is necessary.
>
>
> If you know that you'll need the result of a query beforehand, you
> can always use SELECT ... INTO ... . No client-side features required.
>
> This feature is intended for people running plenty of ad-hoc queries,
> when every result could potentially be useful.
>
> Pavel Stehule <mailto:pavel(dot)stehule(at)gmail(dot)com>
> Monday, July 01, 2013 1:31 AM
> 2013/7/1 Maciej Gajewski<maciej(dot)gajewski0(at)gmail(dot)com>:
>> I'm not really bought into some of the ideas.
>>
>>
>>>> but maybe some interactive mode should be usefull - so after
>>>> execution, and showing result, will be prompt if result should be
>>>> saved or not.
>>> I like the idea, in addition to the ordinary mode. Personally, I would use
>>> the ordinary mode, but I can see how 'interactive' would be useful.
>>>
>> This would require a complex change to the client code. And the result would
>> eventually become annoying: an interactive question after each and every
>> query. Currently, when turned on, every result is stored and simple
>> notification is printed.
>>
> .
> When I tested this feature, I had 30 caches per 5 minutes, and only a
> few from these queries had a sense. Switch between off and on is not
> user friendly. I believe so there can be other solution than mine, but
> a possibility to friendly clean unwanted caches is necessary.
>
>>>> yes, the names :ans01, :ans02, ... miss semantics - How I can join
>>>>
>>>> this name (and content) with some SQL query?
>>> That makes sense. I think having part of / the whole query string would be
>>> very helpful. Great suggestion!
>>>
>> The naming is obscure and non-informative, I agree. If you have a nice idea
>> how to make it better, I'd love to discuss it. But please remember that it
>> has one huge advantage: simplicity. The client is a classical command-line
>> tool, and as such it delegates some of the functionality to external
>> programs, like pager or terminal.
>>
>
> Personally, I don't see a strong price for all users without friendly
> interface.
>
> Regards
>
> Pavel
>
>> I'm pretty sure that your terminal emulator has a 'find' function that would
>> allow you to quickly locate the variable and associated query in the
>> scrollback.
>>
>> M
>>
> Maciej Gajewski <mailto:maciej(dot)gajewski0(at)gmail(dot)com>
> Monday, July 01, 2013 1:23 AM
> I'm not really bought into some of the ideas.
>
>
> but maybe some interactive mode should be usefull - so after
> execution, and showing result, will be prompt if result should be
> saved or not.
>
> I like the idea, in addition to the ordinary mode. Personally, I
> would use the ordinary mode, but I can see how 'interactive' would
> be useful.
>
>
> This would require a complex change to the client code. And the result
> would eventually become annoying: an interactive question after each
> and every query. Currently, when turned on, every result is stored and
> simple notification is printed.
>
> yes, the names :ans01, :ans02, ... miss semantics - How I can join
>
> this name (and content) with some SQL query?
>
> That makes sense. I think having part of / the whole query string
> would be very helpful. Great suggestion!
>
>
>
> The naming is obscure and non-informative, I agree. If you have a nice
> idea how to make it better, I'd love to discuss it. But please
> remember that it has one huge advantage: simplicity. The client is a
> classical command-line tool, and as such it delegates some of the
> functionality to external programs, like pager or terminal.
>
> I'm pretty sure that your terminal emulator has a 'find' function that
> would allow you to quickly locate the variable and associated query in
> the scrollback.
>
> M
>
> ian link <mailto:ian(at)ilink(dot)io>
> Monday, July 01, 2013 12:19 AM
>
> but maybe some interactive mode should be usefull - so after
> execution, and showing result, will be prompt if result should be
> saved or not.
>
> I like the idea, in addition to the ordinary mode. Personally, I would
> use the ordinary mode, but I can see how 'interactive' would be useful.
>
> yes, the names :ans01, :ans02, ... miss semantics - How I can join
>
> this name (and content) with some SQL query?
>
> That makes sense. I think having part of / the whole query string
> would be very helpful. Great suggestion!
>
> Maciej, would you be able/have time to implement these? Or do you need
> any help getting them done?
>
>
>
> On Sun, Jun 30, 2013 at 11:35 PM, Pavel Stehule
> <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>> wrote:
>
> Hello
>
> 2013/7/1 ian link <ian(at)ilink(dot)io <mailto:ian(at)ilink(dot)io>>:
> > Not sure about all of your suggestions. Let me see if I can
> clarify what
> > you're looking for.
> >
> >>
> >> * simply decision if content should be stored in history or not,
> >
> > Do you mean that the user should use a flag to place the result
> of a query
> > into the history?
> > like:
> > --ans SELECT * FROM cities...
> > Not sure if that's what you mean, but it seems kind of
> unnecesary. They can
> > just hit the \ans flag beforehand.
>
> switching off on is not user friendly
>
> but maybe some interactive mode should be usefull - so after
> execution, and showing result, will be prompt if result should be
> saved or not.
>
> some like:
>
> \ans interactive
> > SELECT * FROM pg_proc;
>
> **** result ****
>
> should be saved last result [y, n]?
> > y
> result is saved in :ans22
>
> >
>
>
> >
> >> * simply remove last entry (table) of history
> >
> > That could be useful. What do you think Maciej?
>
> yes, lot of queries is just +/- experiment and you don't would
> store result
>
> >
> >> * queries should be joined to content, only name is not enough
> >
> > Don't know what you mean. Could you try re-wording that?
> >
>
> yes, the names :ans01, :ans02, ... miss semantics - How I can join
> this name (and content) with some SQL query?
>
> I needs to reverese search in SQL of stored caches, and I need a
> information
>
> ans01 SELECT * FROM pg_proc
> ans02 SELECT * FROM ans02 WHERE ...
> ans03 ...
>
> Regards
>
> Pavel
>
> > Ian
> >
> >
> >
> > On Fri, Jun 28, 2013 at 8:49 AM, Pavel Stehule
> <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>>
> > wrote:
> >>
> >> Hello
> >>
> >> I am not sure, this interface is really user friendly
> >>
> >> there is not possible "searching" in history, and not every
> query push
> >> to history some interesting content.
> >>
> >> It require:
> >>
> >> * simply decision if content should be stored in history or not,
> >> * simply remove last entry (table) of history
> >> * queries should be joined to content, only name is not enough
> >>
> >> Regards
> >>
> >> Pavel
> >>
> >> 2013/6/28 Maciej Gajewski <maciej(dot)gajewski0(at)gmail(dot)com
> <mailto:maciej(dot)gajewski0(at)gmail(dot)com>>:
> >> > Thanks for checking the patch!
> >> >
> >> > So what's left to fix?
> >> > * Moving the escaping-related functions to separate module,
> >> > * applying your corrections.
> >> >
> >> > Did I missed anything?
> >> >
> >> > I'll submit corrected patch after the weekend.
> >> >
> >> > M
> >> >
> >
> >
>
>