From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: missing semicolon at end of psql files |
Date: | 2012-09-12 19:20:24 |
Message-ID: | 2006.1347477624@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I was surprised to find that psql -f file.sql with a file such as this
> select 1;
> select 2
> executes both commands even though the second one is not terminated.
> I realize that this is inconsistently handled throughout the system, for
> example libpq APIs don't care about the missing semicolon, but
> interactive psql does.
> But what bothered me about this is that if a file gets truncated by
> accident, there could be an unqualified DELETE or something similar at
> the end.
> Comments?
I'm a little dubious about changing this behavior. As you say, it's
not like we're consistent about requiring semicolons everywhere, and
frankly I think the argument about truncated files is specious.
I've never heard of that actually happening to anybody.
What would you have it do instead? Throw an error? Silently drop
the last command (which would be the same thing, if nobody was paying
attention to the error message)? I think the compatibility lossage
from either would outweigh the benefit.
Now having said that, I've occasionally wished I could *continue*
a command across file boundaries. But I don't think it's worth the
compatibility issues it'd create.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Wagner | 2012-09-12 19:45:26 | Re: ossp-uuid Contrib Patch |
Previous Message | Dmitriy Igrishin | 2012-09-12 18:06:55 | Re: missing semicolon at end of psql files |