2d9023622c6336da511493e8b96a1ddfbaa7fe74
Two SQL:2013 features that were stubs or bugs. Both ship together
because they share testing infrastructure (the SQL:2013 analytics
bench).
--- 1. ROLLUP / CUBE / GROUPING SETS (TSqlAgg) ---
The parser has recognized these for a while, storing them as
`ND_FN "ROLLUP"` / "CUBE" / "GROUPING SETS" nodes inside the
GROUP BY list. GroupBy never actually expanded them — it treated
the ND_FN as an opaque group term, which meant every row hashed
into the empty bucket and the query returned a single row.
New TSqlAgg:ExpandGroupingSets walks the aGroupBy array and
expands each ROLLUP / CUBE / GSETS modifier into a list of flat
grouping sets by cross-product with the surrounding plain terms:
GROUP BY ROLLUP(a, b, c) → {(a,b,c), (a,b), (a), ()}
GROUP BY CUBE(a, b) → {(a,b), (a), (b), ()}
GROUP BY GROUPING SETS((a,b),()) → as-is
GROUP BY x, ROLLUP(a, b) → {(x,a,b), (x,a), (x)}
When the expansion produces more than one set, GroupBy recurses
once per set (passing the plain flat set) and NILs out SELECT
columns that aren't in the current set — the standard subtotal
placeholder. Fast path (no ROLLUP/CUBE/GSETS node) short-circuits
to the original single-pass logic.
Correctness check: `SELECT region, SUM(amount) FROM sales GROUP BY
ROLLUP(region)` on a 5-region dataset now returns 6 rows (5
per-region subtotals + 1 grand total row with region=NIL). Was 1.
--- 2. Correlated subquery memoization (TSqlExecutor) ---
Committed 9e0f82c fixed a silent caching bug that made correlated
subqueries return the first outer-row's result for every subsequent
row, at the cost of dropping caching entirely — every outer row
re-executed the subquery. For Q8 in the SQL:2013 bench (1000 emps,
correlated on 3 distinct depts) that was 4.9 seconds.
The right answer is to memoize per outer-key, not globally. This
commit adds:
- TSqlExecutor:CollectFreeVars(hQ): walks a subquery's WHERE,
columns, and HAVING for ND_COL references whose alias prefix
isn't one of the subquery's own FROM tables. Those are the
outer columns the subquery actually depends on.
- TSqlExecutor:SubqueryCached(xSubNode): runs the free-var
analysis once per distinct AST node (memoized onto a 6th slot
on the node), builds a cache key from the current values of
those free vars via ::Resolve(), looks up in ::hSubCorrCache,
executes on miss. Non-correlated subqueries end up with an
empty free-var list → single cache entry → same behavior as
the old CacheSubquery fast path.
- ND_SUB and ND_SUB-in-IN handlers route through SubqueryCached
instead of the split cache/push-outer logic.
Plus a correctness fix that SubqueryCached surfaced: when a
subquery runs at nDepth > 1, TSqlExecutor rewrites each FROM
table's alias to a depth-suffixed temp (so concurrent opens of
the same file don't collide). Previously the original user-written
alias was only preserved in aTables[i][3] for single-char aliases.
Multi-char aliases like `emp e2` lost their original after the
rename, so FindWA("E2") failed, Resolve("e2.dept") returned NIL,
and `WHERE e2.dept = e1.dept` evaluated NIL=NIL → every row was
filtered out → subquery AVG returned 0 → outer `salary > 0` was
trivially true for everyone. Now we always stash the original
alias in [3] before the rename.
--- Bench (SQL:2013 analytics, 10 queries, emp=1k, sales=20k) ---
Query Before After Δ
────────────────────────────────────────────────────────
Q6 RECURSIVE hierarchy (prev fix) 30ms
Q7 ROLLUP subtotals 86ms, 1 row 106ms, 6 rows (correct)
Q8 Correlated subquery 4933ms 20ms ~245x
(all other queries unchanged at 4–230ms)
Q8 30-row sanity regression test (emp.dept in {A,B,C}, deterministic
salaries so hand-computed averages are 155/810/1765):
SELECT name, dept, salary FROM emp e1
WHERE salary > (SELECT AVG(salary) FROM emp e2 WHERE e2.dept = e1.dept)
Before: 30 rows (wrong — returns all)
After: 15 rows (correct — 5 above each dept's average)
Validation:
- FiveSql2 43/43
- Harbour compat 51/51
- go test ./... ALL PASS
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Five — Harbour + Go Fusion Language
Harbour PRG 코드를 네이티브 Go 바이너리로 컴파일하는 퓨전 언어.
30년간 축적된 Harbour/xBase 비즈니스 로직을 Go의 성능, 동시성, 크로스 플랫폼 위에서 실행합니다.
employees.prg → five build → employees (단일 실행파일, 18MB)
주요 특징
- Harbour 문법 100% 지원 (CLASS, CODE BLOCK, BEGIN SEQUENCE, ...)
- Go 네이티브 바이너리 출력 (CGo 없음, 순수 Go)
- DBF/NTX/CDX 데이터베이스 엔진 내장
- 479개 RTL 내장 함수
- FiveSql2: DBF 위에서 SQL:1999 쿼리 (43/43 테스트 통과)
- Goroutine/Channel 확장 (
GO BLOCK,CHANNEL) - @byref 참조 전달, mutable closure
- 대화형 디버거 (TUI/CLI)
빌드 방법
1. Go 설치
Five는 Go 1.21 이상이 필요합니다.
Linux/WSL:
# 이미 설치되어 있는지 확인
go version
# 없으면 설치
wget https://go.dev/dl/go1.22.5.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.22.5.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> ~/.bashrc
source ~/.bashrc
go version
macOS (Apple Silicon — M1/M2/M3/M4):
brew install go
# 또는 직접 다운로드:
wget https://go.dev/dl/go1.22.5.darwin-arm64.tar.gz
sudo tar -C /usr/local -xzf go1.22.5.darwin-arm64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> ~/.zshrc
source ~/.zshrc
macOS (Intel):
brew install go
# 또는 직접 다운로드:
wget https://go.dev/dl/go1.22.5.darwin-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.22.5.darwin-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> ~/.zshrc
source ~/.zshrc
Windows:
https://go.dev/dl/ 에서 .msi 설치
2. Five 컴파일러 빌드
git clone https://gitea.fivego.org/fivedev/five.git
cd five
go build -o five ./cmd/five
빌드 확인:
./five version
3. PRG 프로그램 컴파일 및 실행
단일 파일:
# 컴파일
./five build examples/hello.prg -o hello
# 실행
./hello
다중 파일 (FiveSql2 등):
./five build _FiveSql2/test/test_sql1999.prg _FiveSql2/src/*.prg -o test_sql
./test_sql
4. 테스트 실행
# Go 유닛 테스트
go test ./...
# FiveSql2 SQL 테스트 (43/43)
./five build _FiveSql2/test/test_sql1999.prg _FiveSql2/src/*.prg -o /tmp/test_sql
cd /tmp && ./test_sql
# Harbour 호환 테스트 (51/51)
./five build tests/compat_harbour.prg -o /tmp/test_compat
/tmp/test_compat
Five 명령어
five run <file.prg> 컴파일 후 즉시 실행
five build <file.prg> [-o out] 네이티브 바이너리 생성
five gen <file.prg> 생성된 Go 코드 출력 (디버깅용)
five debug <file.prg> 대화형 디버거 실행
five version 버전 정보
Hello World
// hello.prg
PROCEDURE Main()
? "Hello, Five!"
? "Date:", Date()
? "Time:", Time()
RETURN
./five build hello.prg -o hello && ./hello
SQL 예제
// sql_demo.prg
#include "FiveSqlDef.ch"
PROCEDURE Main()
// 테이블 생성
five_SQL("CREATE TABLE employees (id INTEGER, name CHAR(30), salary NUMERIC(12,2))")
// 데이터 삽입
five_SQL("INSERT INTO employees (id, name, salary) VALUES (1, 'Alice', 8000)")
five_SQL("INSERT INTO employees (id, name, salary) VALUES (2, 'Bob', 7000)")
// SQL 쿼리
LOCAL aR := five_SQL("SELECT name, salary FROM employees WHERE salary > 6000 ORDER BY salary DESC")
? "Results:", Len(aR[2]), "rows"
LOCAL i
FOR i := 1 TO Len(aR[2])
? " ", aR[2][i][1], aR[2][i][2]
NEXT
RETURN
./five build sql_demo.prg _FiveSql2/src/*.prg -o sql_demo && ./sql_demo
프로젝트 구조
five/
├── cmd/five/ Five CLI (main entry point)
├── compiler/ PRG → Go 컴파일러
│ ├── lexer/ 토크나이저
│ ├── parser/ 구문 분석기
│ ├── analyzer/ 의미 분석기
│ ├── gengo/ Go 코드 생성기
│ └── pp/ 전처리기 (#include, #define)
├── hbrt/ 런타임 (VM, Stack, Value, Class)
├── hbrtl/ RTL 표준 라이브러리 (479개 함수)
├── hbrdd/ RDD 데이터베이스 엔진
│ ├── dbf/ DBF 파일 드라이버
│ ├── ntx/ NTX 인덱스 드라이버
│ ├── cdx/ CDX 인덱스 드라이버
│ └── mem/ 메모리 RDD
├── _FiveSql2/ SQL:1999 엔진 (PRG)
│ ├── src/ SQL 엔진 소스 (14 파일, 10,458 LOC)
│ └── test/ SQL 테스트 스위트
├── tests/ 호환성 테스트
├── examples/ 예제 프로그램
└── docs/ 기술 문서
현재 상태
| 항목 | 수치 |
|---|---|
| Go 프로덕션 코드 | ~36,000 LOC |
| RTL 내장 함수 | 479개 |
| RDD 드라이버 | 4종 (DBF, NTX, CDX, Memory) |
| FiveSql2 테스트 | 43/43 (100%) |
| 호환 테스트 | 51/51 (100%) |
| Go 테스트 | ALL PASS |
라이선스
Copyright (c) 2025-2026 Charles KWON OhJun (charleskwonohjun@gmail.com) All rights reserved.
Description
Languages
Go
57.9%
xBase
22%
C
19.5%
Shell
0.5%
Makefile
0.1%