Karl O. Pinc k...@meme.com writes:
This patch (psql_remove_include.patch) eliminates
the #include of psqlscan.c at the bottom of mainloop.c.
I don't really see that this is enough of an improvement to justify
depending on a non-portable flex feature.
I'm thinking of exposing enough of the
On 09/27/2012 10:07:48 AM, Tom Lane wrote:
Karl O. Pinc k...@meme.com writes:
This patch (psql_remove_include.patch) eliminates
the #include of psqlscan.c at the bottom of mainloop.c.
I don't really see that this is enough of an improvement to justify
depending on a non-portable flex
Excerpts from Karl O. Pinc's message of jue sep 27 12:29:53 -0300 2012:
The reason I want this is because I don't want to have to
rewrite the sql parser in PHP for inclusion in phpPgAdmin.
(I did this once, and it was such a big ugly patch
it never got around to getting into the mainline
On 09/27/12 8:41 AM, Alvaro Herrera wrote:
But I think I see what Tom objection to it is: if we export this
capability to libpq applications, then we set it in stone to a certain
extent: exactly how things are split would become part of the API, so to
speak. Upgrading to a newer libpq could
Alvaro Herrera alvhe...@2ndquadrant.com writes:
But I think I see what Tom objection to it is: if we export this
capability to libpq applications, then we set it in stone to a certain
extent: exactly how things are split would become part of the API, so to
speak. Upgrading to a newer libpq
On 09/27/2012 11:02:42 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@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
On 09/27/2012 11:02:42 AM, Tom Lane wrote:
Rather, the problem is that the server might know about some newer
lexical feature, and so might the application, but if libpq is behind
the times then it's broken.
If the application knows about the newer feature and wants
to use it, is it
Karl O. Pinc k...@meme.com writes:
What I'm thinking of in libpq is the ability to give it big string
with many sql statements and have it hand back each statement
so the client can then submit it to the server for execution.
What I really _want_ is to be able get a bit string of many
sql
Karl O. Pinc k...@meme.com writes:
On 09/27/2012 11:02:42 AM, Tom Lane wrote:
Rather, the problem is that the server might know about some newer
lexical feature, and so might the application, but if libpq is behind
the times then it's broken.
If the application knows about the newer feature
On 09/27/2012 02:28:49 PM, Tom Lane wrote:
Karl O. Pinc k...@meme.com writes:
What I really _want_ is to be able get a bit string of many
sql statements from the user and return the results, statuses,
etc. of executing each statement. Just what psql does when,
say, fed a file from
10 matches
Mail list logo
