Mark Dilger <hornschnorter@gmail.com> writes:
>> On Dec 12, 2015, at 3:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... In general, though, I'd rather not try to
>> teach InteractiveBackend() such a large amount about SQL syntax.
> I use CREATE RULE within startup files in the fork that I maintain. I have
> lots of them, totaling perhaps 50k lines of rule code. I don't think any of that
> code would have a problem with the double-newline separation you propose,
> which seems a more elegant solution to me.
Yeah? Just for proof-of-concept, could you run your startup files with
the postgres.c patch as proposed, and see whether you get any failures?
> Admittedly, the double-newline
> separation would need to be documented at the top of each sql file, otherwise
> it would be quite surprising to those unfamiliar with it.
Agreed, that wouldn't be a bad thing.
I thought of a positive argument not to do the "fully right" thing by
means of implementing the exactly-right command boundary rules. Suppose
that you mess up in information_schema.sql or another large input file
by introducing an extra left parenthesis in some query. What would happen
if InteractiveBackend() were cognizant of the paren-matching rule is that
it would slurp everything till the end-of-file and then produce a syntax
error message quoting all that text; not much better than what happens
today. With a command break rule like semi-newline-newline, there'll be
a limited horizon as to how much text gets swallowed before you get the
error message.
Note that this is different from the situation with a fully interactive
input processor like psql: if you're typing the same thing in psql,
you'll realize as soon as it doesn't execute the command when-expected
that something is wrong. You won't type another thousand lines of input
before looking closely at what you typed already.
I'm still not quite sold on semi-newline-newline as being the best
possible command boundary rule here; but I do think that "fully correct"
boundary rules are less attractive than they might sound.
regards, tom lane