Re: proposal - assign result of query to psql variable
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Erik Rijkers <er@xs4all.nl>, Shigeru HANADA <shigeru.hanada@gmail.com>, David Fetter <david@fetter.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2012-10-15T03:57:42Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix oversight in new code for printing rangetable aliases.
- 8b728e5c6e0c 9.3.0 cited