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 feature.
Ok. (I had no idea it was non-portable. The flex
docs don't mention this.)
>
> > I'm thinking of exposing enough of the psql parser,
> > moving it to libpq, that any client-side app can
> > do what libpq does; given a bunch of sql
> > separated by semi-colons get the results
> > of all the statements. This should also allow
> > the "statement separation" to be done on the client
> > side in libpq. Although I don't imagine that this
> > will have a performance impact on the server side
> > it sounds like a first step toward pushing more of
> > the parsing onto the client.
>
> Quite honestly, I don't like that idea at all either. It's bad
> enough
> that psql has to know so much low-level SQL syntax. If we start
> encouraging other programs to know that, we're going to be locked
> into
> never again making any lexical-level changes. Why exactly is
> "pushing
> parsing onto the client" a good idea?
There's really 2 ideas. I don't care about this one:
pushing parsing/anything onto the client is a good idea because
clients scale horizontally and so performance is improved.
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 from the user and return the results, statuses,
etc. of executing each statement. Just what psql does when,
say, fed a file from stdin.
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 phpPgAdmin.)
phpPgAdmin (pgAdmin/ front-end of your choice)
should be able process a string of sql statements in the
same way that psql does, but currently the only way to
do this is to rewrite the parser in each application.
Much better to have libpq provide the functionality,
although I suppose it's possible to push this into the
server.
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
