> > Google for my previous posts about a preparse() method for my > thinking on handling client-side parsing for placeholders and > SQL translations. (This work hasn't got very far and if it doesn't > soon I'll be asking for volunteers with Parse::RecDescent experience > to step forward.)
Is the purpose of this solely for placeholders, or is this an attempt at a universal SQL syntax (ala ODBC's conformance levels) ? I assume that using existing platform-specific SQL will still be permitted (wo/ lots of ANSI escape clauses) ? (I'd hate to see DBI turn into a LCD-only lib) > > For the binding I really don't want to add new methods, so the > driver would need to be changed to recognise a bind_param to a named > placeholder and get the corresponding set of placeholder index > values to use. > > Now a question to all: which database servers, other than Oracle, > support named placeholders and what syntax do they use? > > Tim. Teradata supports named placeholders. The syntax is :NAME, ie, SELECT * FROM TABLE WHERE COL1 = :col1; (there's also a USING clause prepended to the query to define its datatype, but that can be rendered internally). BTW: I don't see anything in DBI 1.38 that checks for numeric parameter ID in bind_param() (tho bind_param_array() does), so is it safe to assume individual drivers *could* just implement such (non-portable) support on their own (excluding array-binding support, and the "default" binding via execute()/execute_array()). Which also raises the issue of how the default bindings would map to named PHs (perhaps a simple arrayref of the names supplied as an attribute ?) Changing bind_param_array() to support this looks pretty simple. Regards, Dean Arnold Presicient Corp. www.presicient.com
