Re: [HACKERS] Review: query result history in psql

[Ian Link]

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 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 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 Monday, July 01, 2013 1:31 AM 2013/7/1 Maciej Gajewski <maciej.gajews...@gmail.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 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 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.steh...@gmail.com> wrote: Hello 2013/7/1 ian link <i...@ilink.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.steh...@gmail.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.gajews...@gmail.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 >> > > >