> On Dec 12, 2015, at 3:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Joe Conway <mail@joeconway.com> writes:
>> On 12/12/2015 02:31 PM, Tom Lane 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. But if anyone has another simple
>>> rule for breaking SQL into commands, we can certainly discuss
>>> alternatives.
>
>> Possibly inadequate, but I wrote a get_one_query() function to grab one
>> statement at a time from a possibly multi-statement string and it isn't
>> all that many lines of code:
>> https://github.com/jconway/pgsynck/blob/master/pgsynck.c
>
> Hmm. Doesn't look like that handles semicolons embedded in CREATE RULE;
> for that you'd have to track parenthesis nesting as well. (It's arguable
> that we won't ever need that case during initdb, but I'd just as soon not
> wire in such an assumption.) 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. 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.
You mentioned upthread that introducing a syntax error in one of these files
results in a not-so-helpful error message that dumps the contents of the
entire file. I can confirm that happens, and is hardly useful.
mark