On Fri, 2007-06-01 at 09:34 -0400, Art Protin wrote: > First, I must confess. I do not know how to make a module's > attributes read-only.
Um, apparently neither do I ;) I just tried, and informixdb allows me to change its paramstyle attribute. Then again, there are no code paths in informixdb that depend on the paramstyle setting. > Optional keyword arguments are a very good approach & I do like the > inheritance scheme. Would it make sense for paramstyle to be an > attribute > of connection and cursor, that could be read and written? I was kicking around that idea, but I discarded it because it violates the "Single Point Of Truth" principle. If the paramstyle of a cursor can be changed after the cursor is created, the execute calls on that cursor can in general not be sure that the paramstyle is still the one they need. Each execute call would then have to explicitly specify its paramstyle, which defeats the purpose of the inheritance mechanism. The problem is not as pronounced as the problem caused by allowing the user to set the module's paramstyle, because cursors are rarely if ever passed between threads, but a cursor object could conceivably be shared across functions. > I would like autodetection, even prefer autodetection, if I was sure > that it would > work correctly every time no matter what. I am getting more > comfortable with > that hypothesis, but have not yet developed a proof that autodetection > could not > get spoofed. What do you mean by spoofing in this context? Making the parser think that the paramstyle is one thing when it is in reality something else? I think we can make spoofing impossible by definition. In order to spoof the auto-detection, you'd have to make the query contain both false positives (character sequences that aren't parameter markers but are recognized as parameter markers) and false negatives (parameter markers that aren't recognized as such). An adequate query parser MUST always recognize all parameter markers that are present, therefore a parser that permits false negatives is not adequate. [If the parser has to err due to performance reasons, it must err on the side of false positives.] Hence, an adequate parser can not be spoofed. Of course, I've simply transformed the problem to "Does an adequate parser exist for your SQL dialect?" but I think we'll just have to stipulate that the answer is yes. Best regards, -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
