Craig Ringer <cr...@2ndquadrant.com> writes:
> On 13 December 2015 at 06:31, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I'm not particularly wedded to this rule. In principle we could go so
>> far as to import psql's code that parses commands and figures out which
>> semicolons are command terminators --- but that is a pretty large chunk
>> of code, and I think it'd really be overkill considering that initdb
>> deals only with fixed input scripts.
> Shouldn't that be a bison/flex job anyway, rather than hand-coded?
It is, if you're speaking of how psql does it.
I thought about trying to get the backend's existing lexer to do it,
but that code will want to throw an error if it sees unterminated
input (such as an incomplete slash-star comment). I'm not sure that
it'd be a good thing to try to make that lexer serve two masters.
I'm also getting less and less enthused about trying to share code with
psql. In the first place, the backend has no interest in recognizing
psql backslash-commands, nor does it need to deal with some of the weird
constraints psql has like having to handle non-backend-safe encodings.
In the second, while it's reasonable for psql to deal with CREATE RULE
syntax by counting parentheses, there's a good argument that that is
not the behavior we want for noninteractive situations such as reading
information_schema.sql. We won't, for example, have anything
corresponding to psql's changing input prompt to help debug problems.
In the third place, it's just difficult and ugly to write code that
will work in both backend and frontend contexts. We've done it,
certainly, but not for any problem as involved as this would be.
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
