From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Karl O(dot) Pinc" <kop(at)meme(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: psql, remove include of psqlscan.c |
Date: | 2012-09-27 15:07:48 |
Message-ID: | 26500.1348758468@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Karl O. Pinc" <kop(at)meme(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2012-09-27 15:29:53 | Re: psql, remove include of psqlscan.c |
Previous Message | Karl O. Pinc | 2012-09-27 15:00:02 | psql, remove include of psqlscan.c |