- C++ 76.6%
- sql 17%
- Python 2.6%
- C 1.7%
- Julia 0.9%
- Other 1%
### Summary
information_schema.columns has always exposed is_generated and
generation_expression columns (as required by the SQL standard), but
both were hardcoded as NULL::VARCHAR which makes them unusable for
discovering generated columns.
This PR fixes that by:
- Adding is_generated (BOOLEAN) and generation_expression (VARCHAR) to
the `duckdb_columns` table function, sourced from the existing
ColumnDefinition::Generated() and
ColumnDefinition::GeneratedExpression() internals
- Wiring information_schema.columns to use these real values:
is_generated returns 'ALWAYS' or 'NEVER' (consistent with PostgreSQL),
and generation_expression returns the expression string for generated
columns and NULL otherwise
### Before
```
CREATE TABLE t (
i INT,
j INT GENERATED ALWAYS AS (i + 1),
k VARCHAR DEFAULT 'hello'
);
SELECT column_name, is_generated, generation_expression
FROM information_schema.columns WHERE table_name = 't';
-- is_generated and generation_expression are always NULL
```
### After
```
SELECT column_name, is_generated, generation_expression
FROM information_schema.columns WHERE table_name = 't';
-- i | NEVER | NULL
-- j | ALWAYS | CAST((i + 1) AS INTEGER)
-- k | NEVER | NULL
```
### Testing
Extended test/sql/generated_columns/virtual/gcol_duckdb_columns.test
with assertions covering both duckdb_columns and
information_schema.columns.
|
||
|---|---|---|
| .github | ||
| benchmark | ||
| data | ||
| examples | ||
| extension | ||
| logo | ||
| scripts | ||
| src | ||
| test | ||
| third_party | ||
| tools | ||
| .clang-format | ||
| .clang-tidy | ||
| .clangd | ||
| .codecov.yml | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .sanitizer-leak-suppressions.txt | ||
| .sanitizer-thread-suppressions.txt | ||
| AI_POLICY.md | ||
| CITATION.cff | ||
| CLAUDE.md | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Doxyfile | ||
| DuckDBConfig.cmake.in | ||
| DuckDBConfigVersion.cmake.in | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SECURITY.md | ||
DuckDB
DuckDB is a high-performance analytical database system. It is designed to be fast, reliable, portable, and easy to use. DuckDB provides a rich SQL dialect with support far beyond basic SQL. DuckDB supports arbitrary and nested correlated subqueries, window functions, collations, complex types (arrays, structs, maps), and several extensions designed to make SQL easier to use.
DuckDB is available as a standalone CLI application and has clients for Python, R, Java, Wasm, etc., with deep integrations with packages such as pandas and dplyr.
For more information on using DuckDB, please refer to the DuckDB documentation.
Installation
If you want to install DuckDB, please see our installation page for instructions.
Data Import
For CSV files and Parquet files, data import is as simple as referencing the file in the FROM clause:
SELECT * FROM 'myfile.csv';
SELECT * FROM 'myfile.parquet';
Refer to our Data Import section for more information.
SQL Reference
The documentation contains a SQL introduction and reference.
Development
For development, DuckDB requires CMake, Python 3 and a C++17 compliant compiler. In the root directory, run make to compile the sources. For development, use make debug to build a non-optimized debug version. You should run make unit and make allunit to verify that your version works properly after making changes. To test performance, you can run BUILD_BENCHMARK=1 BUILD_TPCH=1 make and then perform several standard benchmarks from the root directory by executing ./build/release/benchmark/benchmark_runner. The details of benchmarks are in our Benchmark Guide.
Please also refer to our Build Guide and Contribution Guide.
Support
See the Support Options page and the dedicated endoflife.date page.