[DB-SIG] API suggestion: expose 'quote' method

Stuart Bishop zen at shangri-la.dropbear.id.au
Wed Jun 4 12:15:22 EDT 2003

Hash: SHA1

On Wednesday, June 4, 2003, at 10:47  AM, David Rushby wrote:

> "If the DMBS client library is nice enough to supply a quoting function
> (either detecting or not detecting types)"?  How would the quoting 
> facility
> be of any value if it didn't detect types?
> As Kevin said in a previous mail:
> """
> Yes, and it works when binding because there is enough context to map 
> each
> parameter to a particular SQL type.  Generic quoting without that 
> context is
> simply not possible without significant infrastructure or meta-data.  
> It is
> a great deal harder than exposing an internal method that already 
> exists
> within a driver.
> """

In what cases is this true, and can these cases be represented as an SQL

> Without support from the native database client library, the Python 
> driver
> would have to fully parse the SQL statement, determine the internal 
> types of
> all the fields its parameters refer to (by looking up metadata in the 
> system
> tables), and then perform the quoting.
> I say that's well outside "the python driver writer's JOB".

I know that *I* can write 'SELECT a FROM b WHERE c = 1' without knowing
that column b in table a has a numeric type, or even caring. You simply
have to quote based on the type of the parameters given to the quote
function. If it is passed as a string, quote it as a string. If it is a 
dbiDate, quote it as a date.

As far as I can see, this trivial approach works happily for generating 
anything that can actually be represented as an SQL command (so if I 
quote(blob) where blob is a 2GB string, I would expect an exception 
me I'm being stupid. But if blob happens to be < 2000 characters and I'm
talking to an Oracle driver I'd expect a nicely quoted ASCII 

- -- 
Stuart Bishop <zen at shangri-la.dropbear.id.au>

Version: GnuPG v1.2.1 (Darwin)


More information about the DB-SIG mailing list