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.
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.
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
PavelWhen 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.2013/7/1 Maciej Gajewski <maciej.gajewski0@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 PavelI'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. MI'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 jointhis 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.Mbut 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 jointhis 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.stehule@gmail.com> wrote:Hello
2013/7/1 ian link <ian@ilink.io>:> Not sure about all of your suggestions. Let me see if I can clarify whatswitching off on is not user friendly
> 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.
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 :ans22yes, lot of queries is just +/- experiment and you don't would store result
>
>
>> * simply remove last entry (table) of history
>
> That could be useful. What do you think Maciej?yes, the names :ans01, :ans02, ... miss semantics - How I can join
>
>> * queries should be joined to content, only name is not enough
>
> Don't know what you mean. Could you try re-wording that?
>
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.stehule@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.gajewski0@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
>> >
>
>
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Hari BabuДата:
Сообщение: Re: Performance Improvement by reducing WAL for Update Operation