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?
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.
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
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
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
the
On Tue, Jul 2, 2013 at 8:16 PM, ian link i...@ilink.io 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'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 each new
2013/7/3 Robert Haas robertmh...@gmail.com:
On Tue, Jul 2, 2013 at 8:16 PM, ian link i...@ilink.io 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
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
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,
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
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.
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 maciej.gajews...@gmail.com:
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
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
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:
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
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 pavel.steh...@gmail.comwrote:
Hello
after patching I
Hello
It's look like my bug - wrong compilation
I am sorry
Pavel
2013/6/28 ian link i...@ilink.io:
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
No worries! :)
On Fri, Jun 28, 2013 at 12:20 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
It's look like my bug - wrong compilation
I am sorry
Pavel
2013/6/28 ian link i...@ilink.io:
I just applied the patch to a clean branch from the latest master. I
couldn't get a
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
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
*
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
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 anything.
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
25 matches
Mail list logo