Re: proposal - assign result of query to psql variable
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Phil Sorber <phil@omniti.com>, Pavel Stehule <pavel.stehule@gmail.com>, Shigeru HANADA <shigeru.hanada@gmail.com>, Erik Rijkers <er@xs4all.nl>, David Fetter <david@fetter.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2012-10-25T14:38:15Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I gave this a look. I think it needs to be revised by somebody with a
> better understanding of scanner (flex) than me, but I didn't like the
> changes in psqlscan.l at all; the new <xvl> pattern is too unlike the
> rest of the surrounding patterns, and furthermore it has been placed
> within the block that says it mirrors the backend scanner, when it
> obviously has no equivalent there.
> I assume there's a better way to do this. Hints would be appreciated.
Personally I saw no reason for this patch to touch psqlscan.l in the
first place. Commands such as \set just scan variable names with
psql_scan_slash_option(OT_NORMAL); why shouldn't this act the same?
Moreover, the proposed lexer rules are flat out *wrong*, in that they
insist on the target variable names being {identifier}s, a restriction
not imposed by \set.
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