On 09/27/2012 02:28:49 PM, Tom Lane wrote:
> "Karl O. Pinc" 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 stdin.
>
"Karl O. Pinc" 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 and
"Karl O. Pinc" 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 statements
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 unreas
On 09/27/2012 11:02:42 AM, Tom Lane wrote:
> Alvaro Herrera 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 lang
Alvaro Herrera 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 could break applicati
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 br
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 p
On 09/27/2012 10:07:48 AM, Tom Lane wrote:
> "Karl O. Pinc" 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
"Karl O. Pinc" 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 psql parser
Hi,
This patch (psql_remove_include.patch) eliminates
the #include of psqlscan.c at the bottom of mainloop.c.
The attached patch uses the %top{} flex feature
introduced in flex 2.5.30 released 2003-4-1.
(See the NEWS file for flex.)
The good news is that config/programs.m4
requires flex >= 2.5
11 matches
Mail list logo
