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 >> > > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers