Re: Review: query result history in psql
От | Ian Link |
---|---|
Тема | Re: Review: query result history in psql |
Дата | |
Msg-id | 51D28465.6030901@ilink.io обсуждение исходный текст |
Ответ на | Re: Review: query result history in psql (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Review: query result history in psql
(Maciej Gajewski <maciej.gajewski0@gmail.com>)
|
Список | pgsql-hackers |
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.
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
PavelMonday, July 01, 2013 4:01 AMWhen 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.Monday, July 01, 2013 1:31 AM2013/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. MMonday, July 01, 2013 1:23 AMI'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.MMonday, July 01, 2013 12:19 AMbut 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