Hello 2012/11/16 Karl O. Pinc <k...@meme.com>: > On 11/03/2012 01:45:36 PM, Pavel Stehule wrote: >> Hello >> >> here is a updated patch > > This message does not appear to be threaded so I'm not > sure I've read the whole back-history. Also, I don't > really know what I'm doing. Never the less, I want > to try to contribute to somebody else's patch so > here's my comments. Make of them what you will. > > I know there's been criticism for touching too many > different parts of the code, but writing your own > mini-lexical analyzer does not make sense to me. > There ought to be a clean way to move that into psqlscan.l > and let lex do it's job.
it is about 20 rows only, so it is not critical and for me is not important where parser is > > Since the result of a \gset is undefined if the query > fails it makes me nervous that psql would > continue running after \gset failure in a > non-interactive environment. Perhaps \gset/psql > should distinguish between interactive and > non-interactive environments in the same way > shell does? Do you have any use-cases where it > makes sense to continue after error in a > non-interactive environment? No, I have not a use case for continuing after error - but any continue after error is risk - so it is similar like any other code - it is same risk as broken output for \g statement forwarded to file and processed later. It can be mentioned in documentation - so preferred usage of this command is in stop error mode > > As long as I'm talking crazy talk, why not > abandon psql as a shell language and instead make a > pl/pgsql interpreter with readlne() in front > of it? Solve all these language-related > issues by using an actual programming language. :-) > I though about it more time, but I don't thinking so this has a sense. Actually we cannot do perfect autocomplete for significantly simpler SQL and there are lot of client side interprets - is not reason for next one. I use psql together bash and it works well. But just very simple task as storing some volatile data for repetitive usage is relative laborious and it is a motivation for this patch. In psql I can simply work with any fields of returned record - what is more terrible work outside psql Regards Pavel Stehuke > I hope at least some of the above is helpful > and I'm not just injecting noise into the system. > > Regards, > > Karl <k...@meme.com> > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
