> On Dec 12, 2015, at 3:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Joe Conway <m...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
