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?
2013/7/3 Robert Haas :
> On Tue, Jul 2, 2013 at 8:16 PM, ian link wrote:
>> We covered that earlier in the email thread, but it's the current name for
>> the query history. I think we are going to change it to something a little
>> more descriptive. I was thinking "qh" for short or "query-history"
>
> 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. It auto-increments with ea
On Tue, Jul 2, 2013 at 8:16 PM, ian link wrote:
> We covered that earlier in the email thread, but it's the current name for
> the query history. I think we are going to change it to something a little
> more descriptive. I was thinking "qh" for short or "query-history".
>
>> I'm not sure if I'll
>
> I haven't been able to find any real documentation on this feature,
> other than the additions to the psql help.
You're right, I missed that in my review. I agree that it needs some more
documentation.
What is "ans"?
We covered that earlier in the email thread, but it's the current name for
On 7/2/13 5:53 AM, Maciej Gajewski wrote:
> In the meantime, I've applied your suggestions and moved the
> sting-manipulating functions to stringutils. Also fixed a tiny bug.
> Patch attached.
I haven't been able to find any real documentation on this feature,
other than the additions to the psql
The query history is stored within the client, so once the user stops
the client, it is gone. But yes, it would be useful to have some tool
that would allow you to see what's in there.
I could be a command (\showans ?) that would list all :ansXXX
variables, together with the query text and the si
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. Ye
2013/7/1 Maciej Gajewski :
>
>> 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
> 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
2013/7/1 Maciej Gajewski :
> 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'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
>
> 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,
Hello
2013/7/1 ian link :
> 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?
>
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 su
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
* qu
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
No worries! :)
On Fri, Jun 28, 2013 at 12:20 AM, Pavel Stehule wrote:
> Hello
>
> It's look like my bug - wrong compilation
>
> I am sorry
>
> Pavel
>
> 2013/6/28 ian link :
> > I just applied the patch to a clean branch from the latest master. I
> > couldn't get a segfault from using the new fe
Hello
It's look like my bug - wrong compilation
I am sorry
Pavel
2013/6/28 ian link :
> I just applied the patch to a clean branch from the latest master. I
> couldn't get a segfault from using the new feature. Could you provide a
> little more info to reproduce the segfault? Thanks
>
>
> On Th
I just applied the patch to a clean branch from the latest master. I
couldn't get a segfault from using the new feature. Could you provide a
little more info to reproduce the segfault? Thanks
On Thu, Jun 27, 2013 at 11:28 PM, Pavel Stehule wrote:
> Hello
>
> after patching I god segfault
>
> Pro
Hello
after patching I god segfault
Program terminated with signal 11, Segmentation fault.
#0 0x0805aab4 in get_prompt (status=PROMPT_READY) at prompt.c:98
98 for (p = prompt_string;
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.i686
ncurses-libs-5.7-9.20100703.fc
>
> It's better to post a review as a reply to the message which contains
> the patch.
Sorry about that, I did not have the email in my inbox and couldn't figure
out how to use the old message ID to send a reply. Here is the thread:
http://www.postgresql.org/message-id/flat/caecsyxjri++t3pevdyzawh
Maciej Gajewski escribió:
> > Those issues aside - I think it's a great feature! I can add the
> > grammatical fixes I made whenever the final patch is ready. Or earlier,
> > whatever works for you. Also, this is my first time reviewing a patch, so
> > please let me know if I can improve on anythi
Thank you for the review!
There were a few english/grammatical mistakes that I went ahead and fixed.
>
Thank you for that. If you could send me a patch-to-a-patch so I can
correct all the mistakes in the next release?
> Additionally, I think some of the string manipulation might be placed
> o
Hi Maciej,
I've been reviewing your patch for the ongoing commitfest. First let me say
that I think it's a great idea and provides some very useful functionality.
However, there are a few minor problems. There were a few
english/grammatical mistakes that I went ahead and fixed. Additionally, I
th
25 matches
Mail list logo
