[DB-SIG] paramstyles, again

[Carsten Haese]

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