"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 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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
