SQL call formatting style

Sergey A. Lipnevich sergeyli at pisem.net
Tue Mar 25 19:47:50 UTC 2003


Jason,

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) 
with almost
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 
page.

Jason Pyeron wrote:
> Sergey,
> 
> 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 
> "\n". 
> 
> 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 mailing list