## How to Create a Range From 1 to 10 in SQL

How do you create a range from 1 to 10 in SQL? Have you ever thought about it? This is such an easy problem to solve in any imperative language, it’s ridiculous. Take Java (or C, whatever) for instance:
```
for (int i = 1; i <= 10; i++)
System.out.println(i);

```
This was easy, right? Things even look more lean when using functional programming. Take Scala, for instance:
```
(1 to 10) foreach { t => println(t) }

```
We could fill about 25 pages about various ways to do the above in Scala, agreeing on how awesome Scala is (or what hipsters we are).

### But how to create a range in SQL?

… And we’ll exclude using stored procedures, because that would be no fun. In SQL, the data source we’re operating on are tables. If we want a range from 1 to 10, we’d probably need a table containing exactly those ten values. Here are a couple of good, bad, and ugly options of doing precisely that in SQL. OK, they’re mostly bad and ugly. By creating a table The dumbest way to do this would be to create an actual temporary table just for that purpose:
```
CREATE TABLE "1 to 10" AS
SELECT 1 value FROM DUAL UNION ALL
SELECT 2       FROM DUAL UNION ALL
SELECT 3       FROM DUAL UNION ALL
SELECT 4       FROM DUAL UNION ALL
SELECT 5       FROM DUAL UNION ALL
SELECT 6       FROM DUAL UNION ALL
SELECT 7       FROM DUAL UNION ALL
SELECT 8       FROM DUAL UNION ALL
SELECT 9       FROM DUAL UNION ALL
SELECT 10      FROM DUAL

```
See also this SQLFiddle This table can then be used in any type of select. Now that’s pretty dumb but straightforward, right? I mean, how many actual records are you going to put in there? By using a VALUES() table constructor This solution isn’t that much better. You can create a derived table and manually add the values from 1 to 10 to that derived table using the `VALUES()` table constructor. In SQL Server, you could write:
```
SELECT V
FROM (
VALUES (1), (2), (3), (4), (5),
(6), (7), (8), (9), (10)
) [1 to 10](V)

```
See also this SQLFiddle By creating enough self-joins of a sufficent number of values Another “dumb”, yet a bit more generic solution would be to create only a certain amount of constant values in a table, view or CTE (e.g. two) and then self join that table enough times to reach the desired range length (e.g. four times). The following example will produce values from 1 to 10, “easily”:
```
WITH T(V) AS (
SELECT 0 FROM DUAL UNION ALL
SELECT 1 FROM DUAL
)
SELECT V FROM (
SELECT 1        +
T1.V +
2 * T2.V +
4 * T3.V +
8 * T4.V V
FROM T T1, T T2, T T3, T T4
)
WHERE V <= 10
ORDER BY V

```
See also this SQLFiddle By using grouping sets Another way to generate large tables is by using grouping sets, or more specifically by using the `CUBE()` function. This works much in a similar way as the previous example when self-joining a table with two records:
```
SELECT ROWNUM FROM (
SELECT 1
FROM DUAL
GROUP BY CUBE(1, 2, 3, 4)
)
WHERE ROWNUM <= 10

```
See also this SQLFiddle By just taking random records from a “large enough” table In Oracle, you could probably use `ALL_OBJECTs`. If you’re only counting to 10, you’ll certainly get enough results from that table:
```
SELECT ROWNUM FROM ALL_OBJECTS
WHERE ROWNUM <= 10

```
See also this SQLFiddle What’s so “awesome” about this solution is that you can cross join that table several times to be sure to get enough values:
```
SELECT ROWNUM
FROM ALL_OBJECTS, ALL_OBJECTS,
ALL_OBJECTS, ALL_OBJECTS
WHERE ROWNUM <= 10

```
OK. Just kidding. Don’t actually do that. Or if you do, don’t blame me if your productive system runs low on memory. By using the awesome PostgreSQL GENERATE_SERIES() function Incredibly, this isn’t part of the SQL standard. Neither is it available in most databases but PostgreSQL, which has the `GENERATE_SERIES()` function. This is much like Scala’s range notation: `(1 to 10)`
```
SELECT * FROM GENERATE_SERIES(1, 10)

```
See also this SQLFiddle By using CONNECT BY If you’re using Oracle, then there’s a really easy way to create such a table using the `CONNECT BY` clause, which is almost as convenient as PostgreSQL’s `GENERATE_SERIES()` function:
```
SELECT LEVEL FROM DUAL
CONNECT BY LEVEL < 10

```
See also this SQLFiddle By using a recursive CTE Recursive common table expressions are cool, yet utterly unreadable. the equivalent of the above Oracle CONNECT BY clause when written using a recursive CTE would look like this:
```
WITH "1 to 10"(V) AS (
SELECT 1 FROM DUAL
UNION ALL
SELECT V + 1 FROM "1 to 10"
WHERE V < 10
)
SELECT * FROM "1 to 10"

```
See also this SQLFiddle By using Oracle’s MODEL clause A decent “best of” comparison of how to do things in SQL wouldn’t be complete without at least one example using Oracle’s MODEL clause (see this awesome use-case for Oracle’s spreadsheet feature). Use this clause only to make your co workers really angry when maintaining your SQL code. Bow before this beauty!
```
SELECT V
FROM (
SELECT 1 V FROM DUAL
) T
MODEL DIMENSION BY (ROWNUM R)
MEASURES (V)
RULES ITERATE (10) (
V[ITERATION_NUMBER] = CV(R) + 1
)
ORDER BY 1

```
See also this SQLFiddle

### Conclusion

There aren’t actually many nice solutions to do such a simple thing in SQL. Clearly, PostgreSQL’s `GENERATE_SERIES()` table function is the most beautiful solution. Oracle’s `CONNECT BY` clause comes close. For all other databases, some trickery has to be applied in one way or another. Unfortunately.

## Subtle SQL differences: IDENTITY columns

As I’m mostly using Oracle, IDENTITY columns were not so important to me up until I started to support them in jOOQ. Then, I found that yet again, there are many differences between various databases in how they handle IDENTITY columns in DDL and in DML.

In SQL, there are essentially three orthogonal concepts of how to identify a record (Please correct me if I may be missing more vendor-specific concepts):

1. Primary Key: This is the most well-known concept. A primary key is the “main unique key” of a table, which means it is a constraint imposed on at least one column. It can be imposed on several columns, too. The primary key has its origin in the relational model
2. Identity: Identities / identity columns are attributed to at most one column per table. They generate a unique ID from a sequence at record insertion – unlike primary keys, which are expected to be inserted correctly by client DML. The identity often coincides with the primary key, but it does not have to. It does not always have to be unique, either
3. ROW ID / OID: Many databases know an internal ID that is usually not used in the logical representation of the database schema. This row id has mostly technical purposes and is also present in tables without primary key or identity columns

### SQL 2008 standard

While primary key constraints are defined pretty much in the same way in every SQL dialect, and ROWID’s are very vendor-specific things, identities are something relatively new. The SQL 1992 standard does not yet define identity columns. They were formally introduced in SQL:2003, only. Here’s a part of the specification:

```<column definition> ::=
<column name> [ <data type or domain name> ]
[ <default clause> | <identity column specification> ]
[ ... ]

<identity column specification> ::=
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
[ <left paren> <common sequence generator options> <right paren> ]
```

This looks neat. In fact, in addition to column constraints, columns can specify an identity generation expression based on a sequence. What does reality look like?

### Reality

DB2, Derby, HSQLDB, Ingres

These SQL dialects implement the standard very neatly.

``` id INTEGER GENERATED BY DEFAULT AS IDENTITY id INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 1) ```

H2, MySQL, Postgres, SQL Server, Sybase ASE, Sybase SQL Anywhere

These SQL dialects implement identites, but the DDL syntax doesn’t follow the standard

``` -- H2 mimicks MySQL's and SQL Server's syntax ID INTEGER IDENTITY(1,1) ID INTEGER AUTO_INCREMENT -- MySQL ID INTEGER NOT NULL AUTO_INCREMENT```

``` -- Postgres serials implicitly create a sequence -- Postgres also allows for selecting from custom sequences -- That way, sequences can be shared among tables id SERIAL NOT NULL ```

```-- SQL Server ID INTEGER IDENTITY(1,1) NOT NULL -- Sybase ASE id INTEGER IDENTITY NOT NULL -- Sybase SQL Anywhere id INTEGER NOT NULL IDENTITY ```

Oracle

Oracle does not know any identity columns at all. Instead, you will have to use a trigger and update the ID column yourself, using a custom sequence. Something along these lines:

``` CREATE OR REPLACE TRIGGER my_trigger BEFORE INSERT ON my_table REFERENCING NEW AS new FOR EACH ROW BEGIN SELECT my_sequence.nextval INTO :new.id FROM dual; END my_trigger; ```

Note, that this approach can be employed in most databases supporting sequences and triggers! It is a lot more flexible than standard identities

SQLite

SQLite does not know any identity columns either. It seems to have MySQL’s AUTO_INCREMENT clause, but in fact this just sets some rules on the ROWID generation, which is not a true identity column according to the SQL standard

### Conclusion

As many things in SQL, identities are a major pain to get correctly when switching databases, or when writing SQL DDL and DML that works correctly across databases.

jOOQ supports DML executed against tables with identity columns and/or trigger-generated ID values. See a previous blog post that further elaborates on the issue:

http://blog.jooq.org/2011/08/29/postgres-insert-returning-clause-and-how-this-can-be-simulated-in-other-rdbms/