jkrueger@dgis.dtic.dla.mil (Jon) (03/16/90)
jas@llama.rtech.UUCP (Jim Shankland) writes: >... I'd rather see support for multiple sessions from a single client ... OK, you got it. It's a feature of modern operating systems called a process. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.
jas@llama.rtech.UUCP (Jim Shankland) (03/17/90)
In article <793@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: >jas@llama.rtech.UUCP (Jim Shankland) writes: > >>... I'd rather see support for multiple sessions from a single client ... > >OK, you got it. It's a feature of modern operating systems called a process. Exactly, though there's a great deal of haggling to be done about process "weight", IPC mechanisms, programming language issues, and so on. Such haggling doesn't particularly belong in comp.databases, which is precisely my point: intra-application parallelism is an OS and/or general-purpose programming language issue; it has no business cluttering up SQL. Not that ... [never mind -- derogatory remark about SQL deleted]. jas
cmorris@ws2s.rtech.COM (Colin Morris) (03/18/90)
In article <5030@rtech.rtech.com> jas@llama.rtech.com (Jim Shankland) writes: >In article <793@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: >>jas@llama.rtech.UUCP (Jim Shankland) writes: >> >>>... I'd rather see support for multiple sessions from a single client ... >> >>OK, you got it. It's a feature of modern operating systems called a process. > >Exactly, though there's a great deal of haggling to be done about >process "weight", IPC mechanisms, programming language issues, and >so on. Such haggling doesn't particularly belong in comp.databases, >which is precisely my point: intra-application parallelism is an >OS and/or general-purpose programming language issue; it has no >business cluttering up SQL. Not exactly. Why force the applications programmer to reinvent the wheel by requiring _him_ to use OS or programming language features to provide the asynchronicity? If SQL itself provides an asynchronous interface, such support can be provided by the SQL vendor, thus freeing the applications programmer from such concerns. Remember, also, that (i) most current programming languages are hardly bastions of parallelism, and (ii) application level parallelism often demands a process-rich environment:- don't assume that all broadly used operating systems provide such an environment. ---- Colin Morris, cmorris@rtech.com Ingres Corp., Alameda, California.
jkrueger@dgis.dtic.dla.mil (Jon) (03/19/90)
cmorris@ws2s.rtech.COM (Colin Morris) writes: >Not exactly. Why force the applications programmer to reinvent the wheel by >requiring _him_ to use OS or programming language features to provide the >asynchronicity? If SQL itself provides an asynchronous interface, such support >can be provided by the SQL vendor, thus freeing the applications programmer >from such concerns. The programmer reinvents the wheel precisely when he doesn't use existing tools appropriate to the job. Moving tools from one box to another is a good move when the new arrangement offers some advantage over the old. Moving all one's tools into a single box seldom confers an advantage. Out-of-order execution of work is a wonderful thing; concerns for safety remain valid and necessary at the present state of the art; no one is freed from this by moving tools to a favorite box. >Remember, also, that (i) most current programming languages are hardly bastions >of parallelism, and (ii) application level parallelism often demands a >process-rich environment:- don't assume that all broadly used operating systems >provide such an environment. If you haven't got the right tools you will indeed find yourself at a disadvantage when you try to do the job. This has nothing to do with how many impoverished tools have been sold in the past. The good news is that some of them can be retrofitted to some extent. You might say your company is in this business :-) -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.
nico@unify.uucp (Nico Nierenberg) (03/20/90)
In article <4990@rtech.rtech.com> jas@llama.rtech.com (Jim Shankland) writes: >In article <3585@infmx.UUCP> perk@infmx.UUCP (Paul Perkovic) writes: >>I might have missed your point, and it may be that no one else >>cares about what's proposed for SQL3, so maybe followups, if >>necessary, should go to email. (In any event, I'll be at ANSI >>meetings for the next few weeks, so I won't be able to respond.) > >Wait! I care. And my initial reaction is, "gag me." I'd rather >see support for multiple sessions from a single client. The client >can then achieve the effect of asynchronous queries by running queries >in separate sessions. > That's ok as long as they can run as the same transaction. Otherwise you could get lock conflicts between your updates and queries. >jas -- --------------------------------------------------------------------- Nicolas Nierenberg "No matter where you go, Unify Corp. there you are." nico@unify
jas@llama.rtech.UUCP (Jim Shankland) (03/20/90)
In article <5045@rtech.rtech.com> cmorris@ws2s.UUCP (Colin Morris) writes: >Why force the applications programmer to reinvent the wheel by >requiring _him_ to use OS or programming language features to provide the >asynchronicity? If SQL itself provides an asynchronous interface, such support >can be provided by the SQL vendor, thus freeing the applications programmer >from such concerns. I'm not sure why it's "reinvent[ing] the wheel" for an application programmer to encode the application's concurrency in, say, Ada, but not in SQL. And asynchronous SQL is of no help at all in the application that wants to do concurrent non-database operations. >Remember, also, that (i) most current programming languages are hardly bastions >of parallelism, and (ii) application level parallelism often demands a >process-rich environment:- don't assume that all broadly used operating systems >provide such an environment. True enough; and asynchronous SQL doesn't exist yet either :-). It will always be tempting to provide some useful feature in SQL that may fill a gap on some antiquated application platform. Such features are bound to be useful to somebody or other. The cost is increased clutter and complexity in SQL. I'm sure somebody would appreciate having: SELECT DNAME, AVG(SALARY) FROM EMP GROUP BY DNAME OUTPUT OPTIONS(POSTSCRIPT, BAR_CHART); Do we really want to oblige? SQL has enough faults as a query language. Adding general-purpose programming features is unlikely to beautify it any. jas
loreen@otl.SanDiego.NCR.COM (Loreen Prinz) (03/20/90)
In article <5045@rtech.rtech.com> cmorris@ws2s.UUCP (Colin Morris) writes: >In article <5030@rtech.rtech.com> jas@llama.rtech.com (Jim Shankland) writes: >>In article <793@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: >>>jas@llama.rtech.UUCP (Jim Shankland) writes: This debate over whether or not asynchronous sql is very interesting to listen to, but could somebody (perhaps you, Colin) please answer the original question: does Ingres support it? (or are there plans to?)
loreen@otl.SanDiego.NCR.COM (Loreen Prinz) (03/20/90)
In article <799@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: >Out-of-order execution of work is a wonderful thing; >concerns for safety remain valid and necessary at the >present state of the art; With asynch sql the statements themselves get executed in the order they are sent to the database server. The main objective is to free up the client to perform other functions. It can then periodically check to see if the sql statement has been completed. -Loreen Prinz NCR Corporation
davidm@uunet.UU.NET (David S. Masterson) (03/21/90)
In article <5051@rtech.rtech.com> jas@llama.rtech.UUCP (Jim Shankland) writes:
SQL has enough faults as a query language. Adding general-purpose
programming features is unlikely to beautify it any.
A general question.
People doing embedded-SQL programming seem to have the most trouble with
switching back and forth between the procedural system and the non-procedural
system. Rather than thinking in terms of beautification, does allowing
general-purpose programming features into SQL actually help the lay-programmer
(as opposed to the lay-user) write better programs against the database?
I'd be interested to hear from programmers working with the Sybase
Transact-SQL system and whether they find it more responsive to their
programming needs or they find the non-ANSI SQL aspects to be an unwanted
extra learning layer.
--
===================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mt. View, CA 94043
===================================================================
"If someone thinks they know what I said, then I didn't say it!"