Re: C lib add-ins

Tony Heskett writes in X-Informix-List-Id: <list.350> > >> would you be looking for and why would a direct C Library help? >How 'bout something like > > select foo > from bar > where dist(x1, y1, x2, y2) < some_number> >dist() figures out how far P1 (x1,y1) is from P2 (x2, y2), and is >part of a C lib that you can add in. V. handy if you're doing >anything complex [sic]. Last time I saw this was in Empress RDBMS. Yeah, but this would just be extensions to the current functions available from Informix SQL (Eg. Count, Sum, Today, User, Length, Date, Day, Current, Extend, etc). I'm sure we could all make a wish list for here but it doesnt require anything more than currently exists and is required for SQL generally not just esql/c. >> The programmer is >> restricted to the SQL commands because otherwise he might?? be >> able to screw up the connection with the backend server. >Don't think so. ESQL/C will let you do some fairly hairy things, >otherwise a simple kill(3) or "tbmode -z $pid" will probably finish >things off. I had got the impression, probably mistakenly, that John was suggesting a more direct access to the functions that actually get parsed into the c programs by the pre-processor to do things like execute, declare, fetch previous/next, etc. If you were to call these in the wrong order or with the wrong parameters you might be able to screw up the sqlexec/turbo. >> so it seems to me that having a pre-processor allows the SQL to be >> kept as readable SQL statements so improving the general >>readability > and maintainability of the code. >The back end parses the SQL normally, so it's kept as readable >statements ? Which is why I might do > LET stmt = "delete from foo where foobar = ? " > PREPARE id FROM stmt > > FOR i = 1 TO 30 > > EXECUTE id USING tmpvar[i] > > END FOR >rather than getting it parsed on every call. Course, if you supply >your own functions, the training and maintainability get much harder >but there are compensations (less code, more effect). Yes, but equally you can add in your own functions at this level if you wanted to. call function() returning i EXECUTE id USING using i the function may have to do a select to get the data it needs. This may be pretty ineffecient which is why getting Informix to add to its current function list would be better. I can see why an open library for select type functions might be useful allowing some users to add there own. But I think it would be better if Informix would publish some standards for these select functions allowing users to provide Informix with public domain functions that meet these standards and these could be included in each new release. This way you wouldn't get problems with functions that they don't support causing select statements to fail. Of course Informix might not provide support for each new PD function for a few releases until the bugs get shaken out but a lot of PD software is pretty clean stuff. Now if Informix was to publish a list of usable functions that can be called from 4gl for handling screens, keyboards, etc to allow you to do things that 4gl doesnt allow directly then I think this would be a great idea. I see no reason why C/Esql-c developers shouldn't be able to have access to this as well. (As long as they buy the licence). As we all use functions that aren't documented it would be a lot easier if Informix would document them, especially as they are the ones who often tell us about them. It would make the product better as well. Cheers, Jim -------------------------------------------------------------------- Name: Jim Gordon Internet: jgordon@ssf-sys.DHL.COM Company: DHL Systems Inc Phone: (415) 358-5911 Address: 1700 S. Amphlett Blvd. Fax: (415) 571-6429 San Mateo, CA 94402 -------------------------------------------------------------------- ALIENS! Unite! Up and at 'em