Re: proposal - assign result of query to psql variable
От | Pavel Stehule |
---|---|
Тема | Re: proposal - assign result of query to psql variable |
Дата | |
Msg-id | CAFj8pRA1W_kZONrqwfvSRCV_c7xWRwC0-9wPkz8J_RJpmgrLAQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal - assign result of query to psql variable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: proposal - assign result of query to psql variable
|
Список | pgsql-hackers |
Hello fast reply 2012/10/14 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> [ gset_08.diff ] > > In the course of adding a new backslash command, this patch manages to > touch: > > * the main loop's concept of what types of backslash commands exist > (PSQL_CMD_NOSEND ... what's the point of that, rather than making > this work the same as \g?) > * SendQuery's concept of how to process command results (again, why > isn't this more like \g?) If I remember, I had to do because I had a problem with shell, but I have to diagnose it again > * ExecQueryUsingCursor's concept of how to process command results > (why? surely we don't need \gset to use a cursor) There was two possibilities, but hardly non using cursor is better way > * the psql lexer (adding a whole bunch of stuff that probably doesn't > belong there) ?? > * the core psql settings construct (to store something that is in > no way a persistent setting) > ?? > Surely there is a less ugly and invasive way to do this. The fact > that the reviewer keeps finding bizarre bugs like "another backslash > command on the same line doesn't work" seems to me to be a good > indication that this is touching things it shouldn't. - all these bugs are based on lexer construct. A little modification of lexer is possible Regards Pavel > > regards, tom lane
В списке pgsql-hackers по дате отправления: