Chris Frey wrote:
> I can imagine a case where a MySQL table uses a C++ keyword as a field name,
> which would require SSQLS to support different names.
I'm not proposing dropping that feature of MySQL++.
SQL allows you to have a table with a column called "My Bizarre Field
Name With Spaces In". You'd have to quote that when building SQL
statements, so you'd need MySQL++ to use the quote manipulator for some
of its features to work. The feature allowing the SSQLS structure to
have different data member names than in the SQL table enters the
picture because you'd also need to use that feature to get your _C++_
syntax correct.
All that having been said, is the auto-quoting part a reasonable thing
to support? By taking advantage of that feature of SQL, you're causing
yourself extra work in generating the SQL, and you're making it
difficult to map the SQL schema directly to C++ data structures. So,
what is the likelihood that you'd see such a field in real world code?
One is rather disincented to take advantage of this feature. [*]
Since having the library behave two different ways for one thing is
wrong, we have a choice. That choice hinges on whether there's any
reasonable argument for real-world code needing quoted field names.
[*] By contrast, you're right to point out that there are other reasons
to use the SSQLS feature than just handling fields with spaces in them.
C++ keywords are a good reason. Now, quoting is also useful for
handling column names with SQL keywords, but I don't believe all SQL
databases allow that. Again there's the question of whether or not the
disincentive to take advantage of this fact is strong enough to make it
unnecessary for MySQL++ to bother supporting it.
Keep in mind while weighing all these options, that if we decide we need
quoting, then field names will always be quoted in generated SQL,
always. That rankles me. It's my argument that it won't be needed
99.99999% of the time, yet it will be there 100% of the time.
