Re: psql, remove include of psqlscan.c

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

In response to

Responses

Browse pgsql-hackers by date

  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