QUEL query languages

Relational database access language

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "QUEL query languages" – news · newspapers · books · scholar · JSTOR (November 2013) (Learn how and when to remove this message)

|

QUEL

Family| Query language
Designed by| Michael Stonebraker
First appeared| 1976; 49 years ago (1976)
Major implementations
Ingres, POSTQUEL
Influenced by
Alpha

QUEL is a relational database query language, based on tuple relational calculus, with some similarities to SQL. It was created as a part of the Ingres DBMS effort at University of California, Berkeley, based on Codd's earlier suggested but not implemented Data Sub-Language ALPHA. QUEL was used for a short time in most products based on the freely available Ingres source code, most notably in an implementation called POSTQUEL supported by POSTGRES.[1]

Eugene Wong of Ingres was the creator of QUEL.[2] As Oracle and IBM DB2 gained market share in the early 1980s, Ingres and other companies supporting QUEL moved to SQL.[3][2] QUEL continues to be available as a part of the Ingres DBMS, although no QUEL-specific language enhancements have been added for many years.[when?]

## Usage

[edit]

QUEL statements are always defined by tuple variables, which can be used to limit queries or return result sets. Consider this example, taken from one of the first original Ingres papers:[4]

range of E is EMPLOYEE
retrieve into W
(COMP = E.Salary / (E.Age - 18))
where E.Name = "Jones"

Here E is a tuple variable that ranges over the EMPLOYEE relation, and all tuples in that relation are found which satisfy the qualification `E.Name = "Jones"`. The result of the query is a new relation W, which has a single domain COMP that has been calculated for each qualifying tuple. Additional queries can then be made against the relation W.

An equivalent SQL statement is:

create table W as
select (E.salary / (E.age - 18)) as COMP
from employee as E
where E.name = 'Jones'

In this example, the relation is being stored in a new table W. This is not a direct analog of the QUEL version; relations in QUEL are more similar to temporary tables seen in most modern SQL implementations.

Here is a sample of a simple session that creates a table, inserts a row into it, and then retrieves and modifies the data inside it and finally deletes the row that was added (assuming that name is a unique field).

QUEL | SQL

|

create student(name = c10, age = i4, sex = c1, state = c2)

range of s is student
append to s (name = "philip", age = 17, sex = "m", state = "FL")

retrieve (s.all) where s.state = "FL"

replace s (age=s.age+1)

retrieve (s.all)

delete s where s.name="philip"

create table student(name char(10), age int, sex char(1), state char(2));

insert into student (name, age, sex, state) values ('philip', 17, 'm', 'FL');

select * from student where state = 'FL';

update student set age=age+1;

select * from student;

delete from student where name='philip';

Another feature of QUEL was a built-in system for moving records en-masse into and out of the system. Consider this command:

copy student(name=c0, comma=d1, age=c0, comma=d1, sex=c0, comma=d1, address=c0, nl=d1)
into "/student.txt"

which creates a comma-delimited file of all the records in the student table. The d1 indicates a delimiter, as opposed to a data type. Changing the into to a from reverses the process. Similar commands are available in many SQL systems, but usually as external tools, as opposed to being internal to the SQL language. This makes them unavailable to stored procedures.

QUEL has an extremely powerful aggregation capability. Aggregates can be nested, and different aggregates can have independent by-lists and/or restriction clauses. For example:

retrieve (a=count(y.i by y.d where y.str = "ii*" or y.str = "foo"), b=max(count(y.i by y.d)))

This example illustrates one of the arguably less desirable quirks of QUEL, namely that all string comparisons are potentially pattern matches. `y.str = "ii*"` matches all `y.str` values starting with ii. In contrast, SQL uses `=` only for exact matches, while like is used when pattern matching is required.

## See also

[edit]

* D4 (programming language) (an implementation of D)
* Relational algebra
* Relational calculus

## References

[edit]

1. ^ Stonebraker, M; Rowe, LA (May 1986). The design of POSTGRES (PDF). Proc. 1986 ACM SIGMOD Conference on Management of Data. Washington, DC.
2. ^ a b "RDBMS Plenary 1: Early Years" (PDF) (Interview). Interviewed by Burton Grad. Computer History Museum. 2007-06-12. p. 26. Retrieved 2025-05-30.
3. ^ Morgenthaler, Gary (2005-12-08). "Oral History of Gary Morgenthaler" (PDF) (Interview). Interviewed by Luann Johnson. Computer History Museum. p. 18. Retrieved 2025-05-30.
4. ^ Stonebraker, Michael; Wong, Eugene; Kreps, Peter; Held, Gerald (1976). "The Design and Implementation of INGRES". ACM Transactions on Database Systems. 1 (3): 191. CiteSeerX 10.1.1.109.957. doi:10.1145/320473.320476.

## Further reading

[edit]

* C. J. Date: A Critique of the SQL Database Language. SIGMOD Record 14(3): 8-54, 1984.

* v
* t
* e

Query languages

In current use|

* .QL
* ALPHA
* CQL
* Cypher
* DAX
* DMX
* Datalog
* GraphQL
* Graph Query Language
* Gremlin
* ISBL
* LDAP
* LINQ
* MQL
* MDX
* OQL
* OCL
* QUEL
* RDF
* SMARTS
* SPARQL
* SQL
* XQuery
* XPath
* YQL

Proprietary|

* YQL
* LINQ

Superseded|

* CODASYL

Authority control databases: National |

* United States
* Israel

|

*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template