SQL call formatting style
Sergey A. Lipnevich
sergeyli at pisem.net
Tue Mar 25 19:47:50 UTC 2003
Then I respectfully disagree with this policy.
I've read Myk's post before replying, and that's more of "let's fill
cars with water because gasoline doesn't smell nice to a driver" kind of
thing. The SQL in code is for the database and for developers, and
administrators would be much better served by a tool which is adequate
for their task. If a malicious user manages to squeeze destructive SQL
code with newlines past Bugzilla, will a good tool show administrators
entire statement or just the first line?
So, administrators need to take care of statements with or without
newlines, and this shouldn't be a reason for makeing developers' life
difficult. By a modest estimation of mine, keeping SQL statements as
sequences of characters uninterrupted by syntax alien to SQL, improves
debugging by the order of mangnitude, which is 10 times.
Besides, newlines mean nothing in SQL and practically nothing in HTML or
XML. Developers must be allowed to use them to their advantage. I'm
writing three page-long SQL statements nowadays (to be executed by DB2)
every significant token or condition on a separate line, and so far both
administrators and testers like them very much -- they can actually read
through them (in the logs or otherwise) as they would an email or a web
Jason Pyeron wrote:
> I understand our policy does not explain why to use a concatenation,
> but here is the gist: when new lines are embedded by formatting it is not
> obvious or explicit as to their existence. It is always better to use a
> This point was supported by Myk's statement:
> ... I find multi-line strings easier to work with, but being able to
> work with the MySQL process list is really important for Bugzilla system
> administrators, so I think we should use concatenation ...
More information about the developers