[Anikesh0001]

Closes #2607

Problem

INDEX name (...) inside CREATE TABLE was parsed, but no index was created. Reproduced on develop (c9e3b53):

alasql('CREATE TABLE t1 (a INT, b INT, INDEX k1 (a))');
alasql('SHOW INDEX FROM t1');       // []
alasql.databases.alasql.indices;    // {}

Cause

As described in the issue: yy.CreateTable.prototype.execute (src/60createtable.js) handles the constraint types PRIMARY KEY, CHECK, UNIQUE and FOREIGN KEY. The parser already produces {type: 'INDEX', indexid, columns, prefixes} for an inline index, and execution skipped it.

Change

A new INDEX branch in the constraint loop registers the index the way CREATE INDEX registers a non-unique index: table.inddefs[name], table.indices[hh] and db.indices[name]. INSERT then keeps it up to date through the existing inddefs loop in table.insert.

The key expression is built the same way CREATE INDEX builds it. A plain column goes through yy.Column#toJS (r['a']). A column with a prefix length (#2606) goes through columnPrefixToJS. So INDEX k (a, b(2)) inside CREATE TABLE gives exactly the same inddefs entry and hash as CREATE INDEX k ON t (a, b(2)). The tests check this.

No grammar or generated parser changes.

Tests

test/test2607.js:

• A: SHOW INDEX lists the index, and db.indices and table.inddefs contain it.
• B: rows inserted after CREATE TABLE are found through the index.
• C: with several columns and a prefix length, the index definition and contents are the same as for CREATE INDEX on an identical table.
• D: several indexes next to a PRIMARY KEY in one CREATE TABLE. Both indexes are created and the primary key is still enforced.

Results:

• bun test ./test/test2607.js against the unchanged src/60createtable.js: 0 pass, 4 fail.
• bun test ./test/test2607.js with this change: 4 pass, 0 fail.
• yarn test-only (full suite, after sh build.sh): 2283 pass, 213 skip, 0 fail. On develop (c9e3b53) before the change: 2279 pass, 213 skip, 0 fail.
• prettier --list-different on both changed files: clean.

I did not run yarn test-browser.

This does not touch queryfn3, so it is independent of #2582.

Note: I used Claude Code to help investigate this issue and draft the change and tests. I reviewed the result, checked that the new tests fail without the fix, and ran the checks above locally.

🤖 Generated with Claude Code