Jonathan Leffler wrote:


For DBD::Informix, with the numbers introduced by me:
1. Yes.
2. Agreed (placeholders are not allowed as either table names or column names).
3. Yes.
4. No.


thanks!    Does the set of 4 questions adequately span the range of issues ?
Or are there questions 5,6 that (once answered) add new info ?



My biggest concern is that you will misinterpret what Informix means if you see colA MATCHES "?foo". If you recognize that 'string' as a delimited identifier in your syntax analyzer, then you will be OK. If you don't recognize that as a single item, then you would be confusing legitimate Informix syntax with a named placeholder. (MATCHES is a variant of LIKE using shell-style metacharacters. Informix is pretty sloppy about allowing both single-quoted and double-quoted strings as strings - unless you force its hand with the DELIMIDENT environment variable.) The other complicating issue would be comment conventions; different drivers have different comment conventions. In particular, Informix supports SELECT * FROM WhereEver WHERE { ?which } x = 3;
Unless your code recognizes that the code inside braces is an Informix comment, it will interpret that ?which as a named placeholder. of course, nothing is ever simple. Informix also recognizes SET { 1, 2, 3 } :: INT as a set of three integers. And you could use placeholders instead of literal integers. That one is ghastly - look at the SQL tokenizer in DBD::Informix...sqltoken.c. Hmmm, there doesn't seem to be iustoken.c in the code - that's a defect. If you want that (which handles the SET and MULTISET and LIST notations which use curly brackets), you'd have to get hold of SQLCMD from the International Informix User Group Software Archive (http://www.iiug.org/software) in the ESQL/C section - or, at a pinch, an older version of SQLCMD, from home.earthlink.net/~jleffler.



Hmm. Im beginning to see why it hasnt already been done :-0


and now that youve raised these complications, I remember a few years ago raging at Oracle cuz
SQL-Plus didnt strip comments before doing placeholder substitution, and had only positional
placeholders. Not a very scalable tool (at that time - dunno about now)


So it seems that comment stripping by DBI would need assistance from the DBD,
ie some sort of calldown which returns a regex that DBI then applies to clean up the SQL.
Presumably there would be some comment syntaxes that DBI could just do w/o help,


$dbh->func('getCommentStripperRegex');


Different comment syntaxes:


Oracle:
     -- comment to end of line...
   /* c style comment (for PL/SQL only?) */

MySQL:
   # perl/shell style comment


BTW - is this the right context ?


$sql = "select * from $sometable where colA in SET {1,2,?three } :: INT"


If you know what a given DBD does, please say so - Im happy to compile it into a succinct capabilities matrix, so I'll start:

module    col-vals-only    tablenames    partial-vals    in( ?foolist)
DBD::CSV:     yes            no             no              no


DBD::Informix yes no no no









Reply via email to