On 09/27/2012 11:02:42 AM, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> A larger point is that I don't believe this is actually going to help
> anybody, because of mismatch of requirements not only implementation
> language. JDBC couldn't use a libpq lexer implementation even
> without
> the language issue, because the context in which they're arguing
> about
> this is finding and replacing JDBC-spec escape sequences, which libpq
> is
> not going to know about. I imagine PHP has got the same problem only
> different. Conversely, psql's lexer has a lot of psql-specific
> design
> decisions, such as the need to handle backslash commands and include
> files, that I don't think would belong in a libpq implementation.
Well no, I'm not at all interested in escape sequences.
I want to take sql directly from the user and execute it.
Right now I can take only one statement at a time.
And this is true of any human-facing application.
I'm not looking for a general purpose solution, although
it did occur to me that the psql variable substitution
mechanism could be exposed.
But what I really want is not "an exposed parser". What
I really want is to be able to get results from all the
statements passed to PQexec (et-al), not just the
last statement. This could be done without exposing
the parser, but it does mean having a parser in libpq.
Since psql links to libpq anyway my plan was to
move the parser entirely out of psql into libpq and
have an undocumented internal interface so that
psql can do the escaping/variable substitution stuff.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein