+
+## Querying the Database Schema
+
+All DuckDB clients support [querying the database schema with SQL]({% link docs/archive/1.0/sql/meta/information_schema.md %}), but the CLI has additional [dot commands]({% link docs/archive/1.0/api/cli/dot_commands.md %}) that can make it easier to understand the contents of a database.
+The `.tables` command will return a list of tables in the database. It has an optional argument that will filter the results according to a [`LIKE` pattern]({% link docs/archive/1.0/sql/functions/pattern_matching.md %}#like).
+
+```sql
+CREATE TABLE swimmers AS SELECT 'duck' AS animal;
+CREATE TABLE fliers AS SELECT 'duck' AS animal;
+CREATE TABLE walkers AS SELECT 'duck' AS animal;
+.tables
+```
+
+```text
+fliers swimmers walkers
+```
+
+For example, to filter to only tables that contain an `l`, use the `LIKE` pattern `%l%`.
+
+```sql
+.tables %l%
+```
+
+```text
+fliers walkers
+```
+
+The `.schema` command will show all of the SQL statements used to define the schema of the database.
+
+```text
+.schema
+```
+
+```sql
+CREATE TABLE fliers (animal VARCHAR);
+CREATE TABLE swimmers (animal VARCHAR);
+CREATE TABLE walkers (animal VARCHAR);
+```
+
+## Configuring the Syntax Highlighter
+
+By default the shell includes support for syntax highlighting.
+The CLI's syntax highlighter can be configured using the following commands.
+
+To turn off the highlighter:
+
+```text
+.highlight on
+```
+
+To turn on the highlighter:
+
+```text
+.highlight off
+```
+
+To configure the color used to highlight constants:
+
+```text
+.constant [red|green|yellow|blue|magenta|cyan|white|brightblack|brightred|brightgreen|brightyellow|brightblue|brightmagenta|brightcyan|brightwhite]
+```
+
+```text
+.constantcode [terminal_code]
+```
+
+To configure the color used to highlight keywords:
+
+```text
+.keyword [red|green|yellow|blue|magenta|cyan|white|brightblack|brightred|brightgreen|brightyellow|brightblue|brightmagenta|brightcyan|brightwhite]
+```
+
+```text
+.keywordcode [terminal_code]
+```
+
+## Importing Data from CSV
+
+> Deprecated This feature is only included for compatibility reasons and may be removed in the future.
+> Use the [`read_csv` function or the `COPY` statement]({% link docs/archive/1.0/data/csv/overview.md %}) to load CSV files.
+
+DuckDB supports [SQL syntax to directly query or import CSV files]({% link docs/archive/1.0/data/csv/overview.md %}), but the CLI-specific commands may be used to import a CSV instead if desired. The `.import` command takes two arguments and also supports several options. The first argument is the path to the CSV file, and the second is the name of the DuckDB table to create. Since DuckDB requires stricter typing than SQLite (upon which the DuckDB CLI is based), the destination table must be created before using the `.import` command. To automatically detect the schema and create a table from a CSV, see the [`read_csv` examples in the import docs]({% link docs/archive/1.0/data/csv/overview.md %}).
+
+In this example, a CSV file is generated by changing to CSV mode and setting an output file location:
+
+```sql
+.mode csv
+.output import_example.csv
+SELECT 1 AS col_1, 2 AS col_2 UNION ALL SELECT 10 AS col1, 20 AS col_2;
+```
+
+Now that the CSV has been written, a table can be created with the desired schema and the CSV can be imported. The output is reset to the terminal to avoid continuing to edit the output file specified above. The `--skip N` option is used to ignore the first row of data since it is a header row and the table has already been created with the correct column names.
+
+```text
+.mode csv
+.output
+CREATE TABLE test_table (col_1 INTEGER, col_2 INTEGER);
+.import import_example.csv test_table --skip 1
+```
+
+Note that the `.import` command utilizes the current `.mode` and `.separator` settings when identifying the structure of the data to import. The `--csv` option can be used to override that behavior.
+
+```text
+.import import_example.csv test_table --skip 1 --csv
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/api/cli/editing.md b/docs/archive/1.0/api/cli/editing.md
new file mode 100644
index 00000000000..aa35847afac
--- /dev/null
+++ b/docs/archive/1.0/api/cli/editing.md
@@ -0,0 +1,100 @@
+---
+layout: docu
+title: Editing
+---
+
+> The linenoise-based CLI editor is currently only available for macOS and Linux.
+
+DuckDB's CLI uses a line-editing library based on [linenoise](https://github.com/antirez/linenoise), which has shortcuts that are based on [Emacs mode of readline](https://readline.kablamo.org/emacs.html). Below is a list of available commands.
+
+## Moving
+
+
+
+| Key | Action |
+|-----------------|------------------------------------------------------------------------|
+| `Left` | Move back a character |
+| `Right` | Move forward a character |
+| `Up` | Move up a line. When on the first line, move to previous history entry |
+| `Down` | Move down a line. When on last line, move to next history entry |
+| `Home` | Move to beginning of buffer |
+| `End` | Move to end of buffer |
+| `Ctrl`+`Left` | Move back a word |
+| `Ctrl`+`Right` | Move forward a word |
+| `Ctrl`+`A` | Move to beginning of buffer |
+| `Ctrl`+`B` | Move back a character |
+| `Ctrl`+`E` | Move to end of buffer |
+| `Ctrl`+`F` | Move forward a character |
+| `Alt`+`Left` | Move back a word |
+| `Alt`+`Right` | Move forward a word |
+
+## History
+
+
+
+| Key | Action |
+|------------|--------------------------------|
+| `Ctrl`+`P` | Move to previous history entry |
+| `Ctrl`+`N` | Move to next history entry |
+| `Ctrl`+`R` | Search the history |
+| `Ctrl`+`S` | Search the history |
+| `Alt`+`<` | Move to first history entry |
+| `Alt`+`>` | Move to last history entry |
+| `Alt`+`N` | Search the history |
+| `Alt`+`P` | Search the history |
+
+## Changing Text
+
+
+
+| Key | Action |
+|-------------------|----------------------------------------------------------|
+| `Backspace` | Delete previous character |
+| `Delete` | Delete next character |
+| `Ctrl`+`D` | Delete next character. When buffer is empty, end editing |
+| `Ctrl`+`H` | Delete previous character |
+| `Ctrl`+`K` | Delete everything after the cursor |
+| `Ctrl`+`T` | Swap current and next character |
+| `Ctrl`+`U` | Delete all text |
+| `Ctrl`+`W` | Delete previous word |
+| `Alt`+`C` | Convert next word to titlecase |
+| `Alt`+`D` | Delete next word |
+| `Alt`+`L` | Convert next word to lowercase |
+| `Alt`+`R` | Delete all text |
+| `Alt`+`T` | Swap current and next word |
+| `Alt`+`U` | Convert next word to uppercase |
+| `Alt`+`Backspace` | Delete previous word |
+| `Alt`+`\` | Delete spaces around cursor |
+
+## Completing
+
+
+
+| Key | Action |
+|---------------|--------------------------------------------------------|
+| `Tab` | Autocomplete. When autocompleting, cycle to next entry |
+| `Shift`+`Tab` | When autocompleting, cycle to previous entry |
+| `Esc`+`Esc` | When autocompleting, revert autocompletion |
+
+## Miscellaneous
+
+
+
+| Key | Action |
+|------------|------------------------------------------------------------------------------------|
+| `Enter` | Execute query. If query is not complete, insert a newline at the end of the buffer |
+| `Ctrl`+`J` | Execute query. If query is not complete, insert a newline at the end of the buffer |
+| `Ctrl`+`C` | Cancel editing of current query |
+| `Ctrl`+`G` | Cancel editing of current query |
+| `Ctrl`+`L` | Clear screen |
+| `Ctrl`+`O` | Cancel editing of current query |
+| `Ctrl`+`X` | Insert a newline after the cursor |
+| `Ctrl`+`Z` | Suspend CLI and return to shell, use `fg` to re-open |
+
+## Using Read-Line
+
+If you prefer, you can use [`rlwrap`](https://github.com/hanslub42/rlwrap) to use read-line directly with the shell. Then, use `Shift`+`Enter` to insert a newline and `Enter` to execute the query:
+
+```bash
+rlwrap --substitute-prompt="D " duckdb -batch
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/api/cli/output_formats.md b/docs/archive/1.0/api/cli/output_formats.md
new file mode 100644
index 00000000000..d11a5223cc5
--- /dev/null
+++ b/docs/archive/1.0/api/cli/output_formats.md
@@ -0,0 +1,81 @@
+---
+layout: docu
+redirect_from:
+- /docs/archive/1.0/api/cli/output-formats
+title: Output Formats
+---
+
+The `.mode` [dot command]({% link docs/archive/1.0/api/cli/dot_commands.md %}) may be used to change the appearance of the tables returned in the terminal output. In addition to customizing the appearance, these modes have additional benefits. This can be useful for presenting DuckDB output elsewhere by redirecting the terminal [output to a file]({% link docs/archive/1.0/api/cli/dot_commands.md %}#output-writing-results-to-a-file). Using the `insert` mode will build a series of SQL statements that can be used to insert the data at a later point.
+The `markdown` mode is particularly useful for building documentation and the `latex` mode is useful for writing academic papers.
+
+
+
+| Mode | Description |
+|--------------|----------------------------------------------|
+| `ascii` | Columns/rows delimited by 0x1F and 0x1E |
+| `box` | Tables using unicode box-drawing characters |
+| `csv` | Comma-separated values |
+| `column` | Output in columns. (See .width) |
+| `duckbox` | Tables with extensive features (default) |
+| `html` | HTML `
+
+### Default DuckDB DSN
+
+The newly installed DSN is visible on the ***System DSN*** in the Windows ODBC Data Source Administrator tool:
+
+
+
+### Changing DuckDB DSN
+
+When selecting the default DSN (i.e., `DuckDB`) or adding a new configuration, the following setup window will display:
+
+
+
+This window allows you to set the DSN and the database file path associated with that DSN.
+
+## More Detailed Windows Setup
+
+There are two ways to configure the ODBC driver, either by altering the registry keys as detailed below,
+or by connecting with [`SQLDriverConnect`](https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqldriverconnect-function?view=sql-server-ver16).
+A combination of the two is also possible.
+
+Furthermore, the ODBC driver supports all the [configuration options]({% link docs/archive/1.0/configuration/overview.md %})
+included in DuckDB.
+
+> If a configuration is set in both the connection string passed to `SQLDriverConnect` and in the `odbc.ini` file,
+> the one passed to `SQLDriverConnect` will take precedence.
+
+For the details of the configuration parameters, see the [ODBC configuration page]({% link docs/archive/1.0/api/odbc/configuration.md %}).
+
+### Registry Keys
+
+The ODBC setup on Windows is based on registry keys (see [Registry Entries for ODBC Components](https://docs.microsoft.com/en-us/sql/odbc/reference/install/registry-entries-for-odbc-components?view=sql-server-ver15)).
+The ODBC entries can be placed at the current user registry key (`HKCU`) or the system registry key (`HKLM`).
+
+We have tested and used the system entries based on `HKLM->SOFTWARE->ODBC`.
+The `odbc_install.exe` changes this entry that has two subkeys: `ODBC.INI` and `ODBCINST.INI`.
+
+The `ODBC.INI` is where users usually insert DSN registry entries for the drivers.
+
+For example, the DSN registry for DuckDB would look like this:
+
+
+
+The `ODBCINST.INI` contains one entry for each ODBC driver and other keys predefined for [Windows ODBC configuration](https://docs.microsoft.com/en-us/sql/odbc/reference/install/registry-entries-for-odbc-components?view=sql-server-ver15).
+
+### Updating the ODBC Driver
+
+When a new version of the ODBC driver is released, installing the new version will overwrite the existing one.
+However, the installer doesn't always update the version number in the registry.
+To ensure the correct version is used,
+check that `HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\DuckDB Driver` has the most recent version,
+and `HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\DuckDB\Driver` has the correct path to the new driver.
\ No newline at end of file
diff --git a/docs/archive/1.0/api/overview.md b/docs/archive/1.0/api/overview.md
new file mode 100644
index 00000000000..cb8dfe8cf72
--- /dev/null
+++ b/docs/archive/1.0/api/overview.md
@@ -0,0 +1,32 @@
+---
+layout: docu
+title: Client APIs Overview
+---
+
+DuckDB is an in-process database system and offers client APIs for several languages. These clients support the same DuckDB file format and SQL syntax. We strived to make their APIs follow their host language's conventions.
+
+Client APIs:
+
+* Standalone [Command Line Interface (CLI)]({% link docs/archive/1.0/api/cli/overview.md %}) client
+* [ADBC API]({% link docs/archive/1.0/api/adbc.md %})
+* [C]({% link docs/archive/1.0/api/c/overview.md %})
+* [C++]({% link docs/archive/1.0/api/cpp.md %})
+* [Go]({% link docs/archive/1.0/api/go.md %}) by [marcboeker](https://github.com/marcboeker)
+* [Java]({% link docs/archive/1.0/api/java.md %})
+* [Julia]({% link docs/archive/1.0/api/julia.md %})
+* [Node.js]({% link docs/archive/1.0/api/nodejs/overview.md %})
+* [ODBC API]({% link docs/archive/1.0/api/odbc/overview.md %})
+* [Python]({% link docs/archive/1.0/api/python/overview.md %})
+* [R]({% link docs/archive/1.0/api/r.md %})
+* [Rust]({% link docs/archive/1.0/api/rust.md %})
+* [Swift]({% link docs/archive/1.0/api/swift.md %})
+* [WebAssembly (Wasm)]({% link docs/archive/1.0/api/wasm/overview.md %})
+
+There are also contributed third-party DuckDB wrappers, which currently do not have an official documentation page:
+
+* [C#](https://github.com/Giorgi/DuckDB.NET) by [Giorgi](https://github.com/Giorgi)
+* [Common Lisp](https://github.com/ak-coram/cl-duckdb) by [ak-coram](https://github.com/ak-coram)
+* [Crystal](https://github.com/amauryt/crystal-duckdb) by [amauryt](https://github.com/amauryt)
+* [Elixir](https://github.com/AlexR2D2/duckdbex) by [AlexR2D2](https://github.com/AlexR2D2/duckdbex)
+* [Ruby](https://github.com/suketa/ruby-duckdb) by [suketa](https://github.com/suketa)
+* [Zig](https://github.com/karlseguin/zuckdb.zig) by [karlseguin](https://github.com/karlseguin)
\ No newline at end of file
diff --git a/docs/archive/1.0/api/python/conversion.md b/docs/archive/1.0/api/python/conversion.md
new file mode 100644
index 00000000000..68a930376e4
--- /dev/null
+++ b/docs/archive/1.0/api/python/conversion.md
@@ -0,0 +1,212 @@
+---
+layout: docu
+redirect_from:
+- /docs/archive/1.0/api/python/result_conversion
+title: Conversion between DuckDB and Python
+---
+
+This page documents the rules for converting [Python objects to DuckDB](#object-conversion-python-object-to-duckdb) and [DuckDB results to Python](#result-conversion-duckdb-results-to-python).
+
+## Object Conversion: Python Object to DuckDB
+
+This is a mapping of Python object types to DuckDB [Logical Types]({% link docs/archive/1.0/sql/data_types/overview.md %}):
+
+* `None` → `NULL`
+* `bool` → `BOOLEAN`
+* `datetime.timedelta` → `INTERVAL`
+* `str` → `VARCHAR`
+* `bytearray` → `BLOB`
+* `memoryview` → `BLOB`
+* `decimal.Decimal` → `DECIMAL` / `DOUBLE`
+* `uuid.UUID` → `UUID`
+
+The rest of the conversion rules are as follows.
+
+### `int`
+
+Since integers can be of arbitrary size in Python, there is not a one-to-one conversion possible for ints.
+Instead we perform these casts in order until one succeeds:
+
+* `BIGINT`
+* `INTEGER`
+* `UBIGINT`
+* `UINTEGER`
+* `DOUBLE`
+
+When using the DuckDB Value class, it's possible to set a target type, which will influence the conversion.
+
+### `float`
+
+These casts are tried in order until one succeeds:
+
+* `DOUBLE`
+* `FLOAT`
+
+### `datetime.datetime`
+
+For `datetime` we will check `pandas.isnull` if it's available and return `NULL` if it returns `true`.
+We check against `datetime.datetime.min` and `datetime.datetime.max` to convert to `-inf` and `+inf` respectively.
+
+If the `datetime` has tzinfo, we will use `TIMESTAMPTZ`, otherwise it becomes `TIMESTAMP`.
+
+### `datetime.time`
+
+If the `time` has tzinfo, we will use `TIMETZ`, otherwise it becomes `TIME`.
+
+### `datetime.date`
+
+`date` converts to the `DATE` type.
+We check against `datetime.date.min` and `datetime.date.max` to convert to `-inf` and `+inf` respectively.
+
+### `bytes`
+
+`bytes` converts to `BLOB` by default, when it's used to construct a Value object of type `BITSTRING`, it maps to `BITSTRING` instead.
+
+### `list`
+
+`list` becomes a `LIST` type of the “most permissive” type of its children, for example:
+
+```python
+my_list_value = [
+ 12345,
+ "test"
+]
+```
+
+Will become `VARCHAR[]` because 12345 can convert to `VARCHAR` but `test` can not convert to `INTEGER`.
+
+```sql
+[12345, test]
+```
+
+### `dict`
+
+The `dict` object can convert to either `STRUCT(...)` or `MAP(..., ...)` depending on its structure.
+If the dict has a structure similar to:
+
+```python
+my_map_dict = {
+ "key": [
+ 1, 2, 3
+ ],
+ "value": [
+ "one", "two", "three"
+ ]
+}
+```
+
+Then we'll convert it to a `MAP` of key-value pairs of the two lists zipped together.
+The example above becomes a `MAP(INTEGER, VARCHAR)`:
+
+```sql
+{1=one, 2=two, 3=three}
+```
+
+> The names of the fields matter and the two lists need to have the same size.
+
+Otherwise we'll try to convert it to a `STRUCT`.
+
+```python
+my_struct_dict = {
+ 1: "one",
+ "2": 2,
+ "three": [1, 2, 3],
+ False: True
+}
+```
+
+Becomes:
+
+```sql
+{'1': one, '2': 2, 'three': [1, 2, 3], 'False': true}
+```
+
+> Every `key` of the dictionary is converted to string.
+
+### `tuple`
+
+`tuple` converts to `LIST` by default, when it's used to construct a Value object of type `STRUCT` it will convert to `STRUCT` instead.
+
+### `numpy.ndarray` and `numpy.datetime64`
+
+`ndarray` and `datetime64` are converted by calling `tolist()` and converting the result of that.
+
+## Result Conversion: DuckDB Results to Python
+
+DuckDB's Python client provides multiple additional methods that can be used to efficiently retrieve data.
+
+### NumPy
+
+* `fetchnumpy()` fetches the data as a dictionary of NumPy arrays
+
+### Pandas
+
+* `df()` fetches the data as a Pandas DataFrame
+* `fetchdf()` is an alias of `df()`
+* `fetch_df()` is an alias of `df()`
+* `fetch_df_chunk(vector_multiple)` fetches a portion of the results into a DataFrame. The number of rows returned in each chunk is the vector size (2048 by default) * vector_multiple (1 by default).
+
+### Apache Arrow
+
+* `arrow()` fetches the data as an [Arrow table](https://arrow.apache.org/docs/python/generated/pyarrow.Table.html)
+* `fetch_arrow_table()` is an alias of `arrow()`
+* `fetch_record_batch(chunk_size)` returns an [Arrow record batch reader](https://arrow.apache.org/docs/python/generated/pyarrow.ipc.RecordBatchStreamReader.html) with `chunk_size` rows per batch
+
+### Polars
+
+* `pl()` fetches the data as a Polars DataFrame
+
+### Examples
+
+Below are some examples using this functionality. See the [Python guides]({% link docs/archive/1.0/guides/overview.md %}#python-client) for more examples.
+
+Fetch as Pandas DataFrame:
+
+```python
+df = con.execute("SELECT * FROM items").fetchdf()
+print(df)
+```
+
+```text
+ item value count
+0 jeans 20.0 1
+1 hammer 42.2 2
+2 laptop 2000.0 1
+3 chainsaw 500.0 10
+4 iphone 300.0 2
+```
+
+Fetch as dictionary of NumPy arrays:
+
+```python
+arr = con.execute("SELECT * FROM items").fetchnumpy()
+print(arr)
+```
+
+```text
+{'item': masked_array(data=['jeans', 'hammer', 'laptop', 'chainsaw', 'iphone'],
+ mask=[False, False, False, False, False],
+ fill_value='?',
+ dtype=object), 'value': masked_array(data=[20.0, 42.2, 2000.0, 500.0, 300.0],
+ mask=[False, False, False, False, False],
+ fill_value=1e+20), 'count': masked_array(data=[1, 2, 1, 10, 2],
+ mask=[False, False, False, False, False],
+ fill_value=999999,
+ dtype=int32)}
+```
+
+Fetch as an Arrow table. Converting to Pandas afterwards just for pretty printing:
+
+```python
+tbl = con.execute("SELECT * FROM items").fetch_arrow_table()
+print(tbl.to_pandas())
+```
+
+```text
+ item value count
+0 jeans 20.00 1
+1 hammer 42.20 2
+2 laptop 2000.00 1
+3 chainsaw 500.00 10
+4 iphone 300.00 2
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/api/python/data_ingestion.md b/docs/archive/1.0/api/python/data_ingestion.md
new file mode 100644
index 00000000000..6399def4260
--- /dev/null
+++ b/docs/archive/1.0/api/python/data_ingestion.md
@@ -0,0 +1,195 @@
+---
+layout: docu
+title: Data Ingestion
+---
+
+This page contains examples for data ingestion to Python using DuckDB. First, import the DuckDB page:
+
+```python
+import duckdb
+```
+
+Then, proceed with any of the following sections.
+
+## CSV Files
+
+CSV files can be read using the `read_csv` function, called either from within Python or directly from within SQL. By default, the `read_csv` function attempts to auto-detect the CSV settings by sampling from the provided file.
+
+Read from a file using fully auto-detected settings:
+
+```python
+duckdb.read_csv("example.csv")
+```
+
+Read multiple CSV files from a folder:
+
+```python
+duckdb.read_csv("folder/*.csv")
+```
+
+Specify options on how the CSV is formatted internally:
+
+```python
+duckdb.read_csv("example.csv", header = False, sep = ",")
+```
+
+Override types of the first two columns:
+
+```python
+duckdb.read_csv("example.csv", dtype = ["int", "varchar"])
+```
+
+Directly read a CSV file from within SQL:
+
+```python
+duckdb.sql("SELECT * FROM 'example.csv'")
+```
+
+Call `read_csv` from within SQL:
+
+```python
+duckdb.sql("SELECT * FROM read_csv('example.csv')")
+```
+
+See the [CSV Import]({% link docs/archive/1.0/data/csv/overview.md %}) page for more information.
+
+## Parquet Files
+
+Parquet files can be read using the `read_parquet` function, called either from within Python or directly from within SQL.
+
+Read from a single Parquet file:
+
+```python
+duckdb.read_parquet("example.parquet")
+```
+
+Read multiple Parquet files from a folder:
+
+```python
+duckdb.read_parquet("folder/*.parquet")
+```
+
+Read a Parquet file over [https]({% link docs/archive/1.0/extensions/httpfs/overview.md %}):
+
+```python
+duckdb.read_parquet("https://some.url/some_file.parquet")
+```
+
+Read a list of Parquet files:
+
+```python
+duckdb.read_parquet(["file1.parquet", "file2.parquet", "file3.parquet"])
+```
+
+Directly read a Parquet file from within SQL:
+
+```python
+duckdb.sql("SELECT * FROM 'example.parquet'")
+```
+
+Call `read_parquet` from within SQL:
+
+```python
+duckdb.sql("SELECT * FROM read_parquet('example.parquet')")
+```
+
+See the [Parquet Loading]({% link docs/archive/1.0/data/parquet/overview.md %}) page for more information.
+
+## JSON Files
+
+JSON files can be read using the `read_json` function, called either from within Python or directly from within SQL. By default, the `read_json` function will automatically detect if a file contains newline-delimited JSON or regular JSON, and will detect the schema of the objects stored within the JSON file.
+
+Read from a single JSON file:
+
+```python
+duckdb.read_json("example.json")
+```
+
+Read multiple JSON files from a folder:
+
+```python
+duckdb.read_json("folder/*.json")
+```
+
+Directly read a JSON file from within SQL:
+
+```python
+duckdb.sql("SELECT * FROM 'example.json'")
+```
+
+Call `read_json` from within SQL:
+
+```python
+duckdb.sql("SELECT * FROM read_json_auto('example.json')")
+```
+
+## Directly Accessing DataFrames and Arrow Objects
+
+DuckDB is automatically able to query certain Python variables by referring to their variable name (as if it was a table).
+These types include the following: Pandas DataFrame, Polars DataFrame, Polars LazyFrame, NumPy arrays, [relations]({% link docs/archive/1.0/api/python/relational_api.md %}), and Arrow objects.
+Accessing these is made possible by [replacement scans]({% link docs/archive/1.0/api/c/replacement_scans.md %}).
+
+DuckDB supports querying multiple types of Apache Arrow objects including [tables](https://arrow.apache.org/docs/python/generated/pyarrow.Table.html), [datasets](https://arrow.apache.org/docs/python/generated/pyarrow.dataset.Dataset.html), [RecordBatchReaders](https://arrow.apache.org/docs/python/generated/pyarrow.ipc.RecordBatchStreamReader.html), and [scanners](https://arrow.apache.org/docs/python/generated/pyarrow.dataset.Scanner.html). See the Python [guides]({% link docs/archive/1.0/guides/overview.md %}#python-client) for more examples.
+
+```python
+import duckdb
+import pandas as pd
+
+test_df = pd.DataFrame.from_dict({"i": [1, 2, 3, 4], "j": ["one", "two", "three", "four"]})
+print(duckdb.sql("SELECT * FROM test_df").fetchall())
+```
+
+```text
+[(1, 'one'), (2, 'two'), (3, 'three'), (4, 'four')]
+```
+
+DuckDB also supports “registering” a DataFrame or Arrow object as a virtual table, comparable to a SQL `VIEW`. This is useful when querying a DataFrame/Arrow object that is stored in another way (as a class variable, or a value in a dictionary). Below is a Pandas example:
+
+If your Pandas DataFrame is stored in another location, here is an example of manually registering it:
+
+```python
+import duckdb
+import pandas as pd
+
+my_dictionary = {}
+my_dictionary["test_df"] = pd.DataFrame.from_dict({"i": [1, 2, 3, 4], "j": ["one", "two", "three", "four"]})
+duckdb.register("test_df_view", my_dictionary["test_df"])
+print(duckdb.sql("SELECT * FROM test_df_view").fetchall())
+```
+
+```text
+[(1, 'one'), (2, 'two'), (3, 'three'), (4, 'four')]
+```
+
+You can also create a persistent table in DuckDB from the contents of the DataFrame (or the view):
+
+```python
+# create a new table from the contents of a DataFrame
+con.execute("CREATE TABLE test_df_table AS SELECT * FROM test_df")
+# insert into an existing table from the contents of a DataFrame
+con.execute("INSERT INTO test_df_table SELECT * FROM test_df")
+```
+
+### Pandas DataFrames – `object` Columns
+
+`pandas.DataFrame` columns of an `object` dtype require some special care, since this stores values of arbitrary type.
+To convert these columns to DuckDB, we first go through an analyze phase before converting the values.
+In this analyze phase a sample of all the rows of the column are analyzed to determine the target type.
+This sample size is by default set to 1000.
+If the type picked during the analyze step is incorrect, this will result in a "Failed to cast value:" error, in which case you will need to increase the sample size.
+The sample size can be changed by setting the `pandas_analyze_sample` config option.
+
+```python
+# example setting the sample size to 100k
+duckdb.execute("SET GLOBAL pandas_analyze_sample = 100_000")
+```
+
+### Registering Objects
+
+You can register Python objects as DuckDB tables using the [`DuckDBPyConnection.register()` function]({% link docs/archive/1.0/api/python/reference/index.md %}#duckdb.DuckDBPyConnection.register).
+
+The precedence of objects with the same name is as follows:
+
+* Objects explicitly registered via `DuckDBPyConnection.register()`
+* Native DuckDB tables and views
+* [Replacement scans]({% link docs/archive/1.0/api/c/replacement_scans.md %})
\ No newline at end of file
diff --git a/docs/archive/1.0/api/python/dbapi.md b/docs/archive/1.0/api/python/dbapi.md
new file mode 100644
index 00000000000..7f3a180878d
--- /dev/null
+++ b/docs/archive/1.0/api/python/dbapi.md
@@ -0,0 +1,172 @@
+---
+layout: docu
+title: Python DB API
+---
+
+The standard DuckDB Python API provides a SQL interface compliant with the [DB-API 2.0 specification described by PEP 249](https://www.python.org/dev/peps/pep-0249/) similar to the [SQLite Python API](https://docs.python.org/3.7/library/sqlite3.html).
+
+## Connection
+
+To use the module, you must first create a `DuckDBPyConnection` object that represents a connection to a database.
+This is done through the [`duckdb.connect`]({% link docs/archive/1.0/api/python/reference/index.md %}#duckdb.connect) method.
+
+The 'config' keyword argument can be used to provide a `dict` that contains key->value pairs referencing [settings]({% link docs/archive/1.0/configuration/overview.md %}#configuration-reference) understood by DuckDB.
+
+### In-Memory Connection
+
+The special value `:memory:` can be used to create an **in-memory database**. Note that for an in-memory database no data is persisted to disk (i.e., all data is lost when you exit the Python process).
+
+#### Named in-memory Connections
+
+The special value `:memory:` can also be postfixed with a name, for example: `:memory:conn3`.
+When a name is provided, subsequent `duckdb.connect` calls will create a new connection to the same database, sharing the catalogs (views, tables, macros etc..).
+
+Using `:memory:` without a name will always create a new and separate database instance.
+
+### Default Connection
+
+By default we create an (unnamed) **in-memory-database** that lives inside the `duckdb` module.
+Every method of `DuckDBPyConnection` is also available on the `duckdb` module, this connection is what's used by these methods.
+
+The special value `:default:` can be used to get this default connection.
+
+### File-Based Connection
+
+If the `database` is a file path, a connection to a persistent database is established.
+If the file does not exist the file will be created (the extension of the file is irrelevant and can be `.db`, `.duckdb` or anything else).
+
+#### `read_only` Connections
+
+If you would like to connect in read-only mode, you can set the `read_only` flag to `True`. If the file does not exist, it is **not** created when connecting in read-only mode.
+Read-only mode is required if multiple Python processes want to access the same database file at the same time.
+
+```python
+import duckdb
+
+duckdb.execute("CREATE TABLE tbl AS SELECT 42 a")
+con = duckdb.connect(":default:")
+con.sql("SELECT * FROM tbl")
+# or
+duckdb.default_connection.sql("SELECT * FROM tbl")
+```
+
+```text
+┌───────┐
+│ a │
+│ int32 │
+├───────┤
+│ 42 │
+└───────┘
+```
+
+```python
+import duckdb
+
+# to start an in-memory database
+con = duckdb.connect(database = ":memory:")
+# to use a database file (not shared between processes)
+con = duckdb.connect(database = "my-db.duckdb", read_only = False)
+# to use a database file (shared between processes)
+con = duckdb.connect(database = "my-db.duckdb", read_only = True)
+# to explicitly get the default connection
+con = duckdb.connect(database = ":default:")
+```
+
+If you want to create a second connection to an existing database, you can use the `cursor()` method. This might be useful for example to allow parallel threads running queries independently. A single connection is thread-safe but is locked for the duration of the queries, effectively serializing database access in this case.
+
+Connections are closed implicitly when they go out of scope or if they are explicitly closed using `close()`. Once the last connection to a database instance is closed, the database instance is closed as well.
+
+## Querying
+
+SQL queries can be sent to DuckDB using the `execute()` method of connections. Once a query has been executed, results can be retrieved using the `fetchone` and `fetchall` methods on the connection. `fetchall` will retrieve all results and complete the transaction. `fetchone` will retrieve a single row of results each time that it is invoked until no more results are available. The transaction will only close once `fetchone` is called and there are no more results remaining (the return value will be `None`). As an example, in the case of a query only returning a single row, `fetchone` should be called once to retrieve the results and a second time to close the transaction. Below are some short examples:
+
+```python
+# create a table
+con.execute("CREATE TABLE items (item VARCHAR, value DECIMAL(10, 2), count INTEGER)")
+# insert two items into the table
+con.execute("INSERT INTO items VALUES ('jeans', 20.0, 1), ('hammer', 42.2, 2)")
+
+# retrieve the items again
+con.execute("SELECT * FROM items")
+print(con.fetchall())
+# [('jeans', Decimal('20.00'), 1), ('hammer', Decimal('42.20'), 2)]
+
+# retrieve the items one at a time
+con.execute("SELECT * FROM items")
+print(con.fetchone())
+# ('jeans', Decimal('20.00'), 1)
+print(con.fetchone())
+# ('hammer', Decimal('42.20'), 2)
+print(con.fetchone()) # This closes the transaction. Any subsequent calls to .fetchone will return None
+# None
+```
+
+The `description` property of the connection object contains the column names as per the standard.
+
+### Prepared Statements
+
+DuckDB also supports [prepared statements]({% link docs/archive/1.0/sql/query_syntax/prepared_statements.md %}) in the API with the `execute` and `executemany` methods. The values may be passed as an additional parameter after a query that contains `?` or `$1` (dollar symbol and a number) placeholders. Using the `?` notation adds the values in the same sequence as passed within the Python parameter. Using the `$` notation allows for values to be reused within the SQL statement based on the number and index of the value found within the Python parameter. Values are converted according to the [conversion rules]({% link docs/archive/1.0/api/python/conversion.md %}#object-conversion-python-object-to-duckdb).
+
+Here are some examples. First, insert a row using a [prepared statement]({% link docs/archive/1.0/sql/query_syntax/prepared_statements.md %}):
+
+```python
+con.execute("INSERT INTO items VALUES (?, ?, ?)", ["laptop", 2000, 1])
+```
+
+Second, insert several rows using a [prepared statement]({% link docs/archive/1.0/sql/query_syntax/prepared_statements.md %}):
+
+```python
+con.executemany("INSERT INTO items VALUES (?, ?, ?)", [["chainsaw", 500, 10], ["iphone", 300, 2]] )
+```
+
+Query the database using a [prepared statement]({% link docs/archive/1.0/sql/query_syntax/prepared_statements.md %}):
+
+```python
+con.execute("SELECT item FROM items WHERE value > ?", [400])
+print(con.fetchall())
+```
+
+```text
+[('laptop',), ('chainsaw',)]
+```
+
+Query using the `$` notation for a [prepared statement]({% link docs/archive/1.0/sql/query_syntax/prepared_statements.md %}) and reused values:
+
+```python
+con.execute("SELECT $1, $1, $2", ["duck", "goose"])
+print(con.fetchall())
+```
+
+```text
+[('duck', 'duck', 'goose')]
+```
+
+> Warning Do *not* use `executemany` to insert large amounts of data into DuckDB. See the [data ingestion page]({% link docs/archive/1.0/api/python/data_ingestion.md %}) for better options.
+
+## Named Parameters
+
+Besides the standard unnamed parameters, like `$1`, `$2` etc., it's also possible to supply named parameters, like `$my_parameter`.
+When using named parameters, you have to provide a dictionary mapping of `str` to value in the `parameters` argument.
+An example use is the following:
+
+```python
+import duckdb
+
+res = duckdb.execute("""
+ SELECT
+ $my_param,
+ $other_param,
+ $also_param
+ """,
+ {
+ "my_param": 5,
+ "other_param": "DuckDB",
+ "also_param": [42]
+ }
+).fetchall()
+print(res)
+```
+
+```text
+[(5, 'DuckDB', [42])]
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/api/python/expression.md b/docs/archive/1.0/api/python/expression.md
new file mode 100644
index 00000000000..b62f1bc9916
--- /dev/null
+++ b/docs/archive/1.0/api/python/expression.md
@@ -0,0 +1,172 @@
+---
+layout: docu
+title: Expression API
+---
+
+The `Expression` class represents an instance of an [expression]({% link docs/archive/1.0/sql/expressions/overview.md %}).
+
+## Why Would I Use the Expression API?
+
+Using this API makes it possible to dynamically build up expressions, which are typically created by the parser from the query string.
+This allows you to skip that and have more fine-grained control over the used expressions.
+
+Below is a list of currently supported expressions that can be created through the API.
+
+## Column Expression
+
+This expression references a column by name.
+
+```python
+import duckdb
+import pandas as pd
+
+df = pd.DataFrame({
+ 'a': [1, 2, 3, 4],
+ 'b': [True, None, False, True],
+ 'c': [42, 21, 13, 14]
+})
+
+# selecting a single column
+col = duckdb.ColumnExpression('a')
+res = duckdb.df(df).select(col).fetchall()
+print(res)
+# [(1,), (2,), (3,), (4,)]
+
+# selecting multiple columns
+col_list = [
+ duckdb.ColumnExpression('a') * 10,
+ duckdb.ColumnExpression('b').isnull(),
+ duckdb.ColumnExpression('c') + 5
+ ]
+res = duckdb.df(df).select(*col_list).fetchall()
+print(res)
+# [(10, False, 47), (20, True, 26), (30, False, 18), (40, False, 19)]
+```
+
+## Star Expression
+
+This expression selects all columns of the input source.
+
+Optionally it's possible to provide an `exclude` list to filter out columns of the table.
+This `exclude` list can contain either strings or Expressions.
+
+```python
+import duckdb
+import pandas as pd
+
+df = pd.DataFrame({
+ 'a': [1, 2, 3, 4],
+ 'b': [True, None, False, True],
+ 'c': [42, 21, 13, 14]
+})
+
+star = duckdb.StarExpression(exclude = ['b'])
+res = duckdb.df(df).select(star).fetchall()
+print(res)
+# [(1, 42), (2, 21), (3, 13), (4, 14)]
+```
+
+## Constant Expression
+
+This expression contains a single value.
+
+```python
+import duckdb
+import pandas as pd
+
+df = pd.DataFrame({
+ 'a': [1, 2, 3, 4],
+ 'b': [True, None, False, True],
+ 'c': [42, 21, 13, 14]
+})
+
+const = duckdb.ConstantExpression('hello')
+res = duckdb.df(df).select(const).fetchall()
+print(res)
+# [('hello',), ('hello',), ('hello',), ('hello',)]
+```
+
+## Case Expression
+
+This expression contains a `CASE WHEN (...) THEN (...) ELSE (...) END` expression.
+By default `ELSE` is `NULL` and it can be set using `.else(value = ...)`.
+Additional `WHEN (...) THEN (...)` blocks can be added with `.when(condition = ..., value = ...)`.
+
+```python
+import duckdb
+import pandas as pd
+from duckdb import (
+ ConstantExpression,
+ ColumnExpression,
+ CaseExpression
+)
+
+df = pd.DataFrame({
+ 'a': [1, 2, 3, 4],
+ 'b': [True, None, False, True],
+ 'c': [42, 21, 13, 14]
+})
+
+hello = ConstantExpression('hello')
+world = ConstantExpression('world')
+
+case = \
+ CaseExpression(condition = ColumnExpression('b') == False, value = world) \
+ .otherwise(hello)
+res = duckdb.df(df).select(case).fetchall()
+print(res)
+# [('hello',), ('hello',), ('world',), ('hello',)]
+```
+
+## Function Expression
+
+This expression contains a function call.
+It can be constructed by providing the function name and an arbitrary amount of Expressions as arguments.
+
+```python
+import duckdb
+import pandas as pd
+from duckdb import (
+ ConstantExpression,
+ ColumnExpression,
+ FunctionExpression
+)
+
+df = pd.DataFrame({
+ 'a': [
+ 'test',
+ 'pest',
+ 'text',
+ 'rest',
+ ]
+})
+
+ends_with = FunctionExpression('ends_with', ColumnExpression('a'), ConstantExpression('est'))
+res = duckdb.df(df).select(ends_with).fetchall()
+print(res)
+# [(True,), (True,), (False,), (True,)]
+```
+
+## Common Operations
+
+The Expression class also contains many operations that can be applied to any Expression type.
+
+| Operation | Description |
+|--------------------------------|----------------------------------------------------------------------------------------------------------------|
+| `.alias(name: str)` | Applies an alias to the expression. |
+| `.cast(type: DuckDBPyType)` | Applies a cast to the provided type on the expression. |
+| `.isin(*exprs: Expression)` | Creates an [`IN` expression]({% link docs/archive/1.0/sql/expressions/in.md %}#in) against the provided expressions as the list. |
+| `.isnotin(*exprs: Expression)` | Creates a [`NOT IN` expression]({% link docs/archive/1.0/sql/expressions/in.md %}#not-in) against the provided expressions as the list. |
+| `.isnotnull()` | Checks whether the expression is not `NULL`. |
+| `.isnull()` | Checks whether the expression is `NULL`. |
+
+### Order Operations
+
+When expressions are provided to `DuckDBPyRelation.order()`, the following order operations can be applied.
+
+| Operation | Description |
+|--------------------------------|----------------------------------------------------------------------------------------------------------------|
+| `.asc()` | Indicates that this expression should be sorted in ascending order. |
+| `.desc()` | Indicates that this expression should be sorted in descending order. |
+| `.nulls_first()` | Indicates that the nulls in this expression should precede the non-null values. |
+| `.nulls_last()` | Indicates that the nulls in this expression should come after the non-null values. |
\ No newline at end of file
diff --git a/docs/archive/1.0/api/python/function.md b/docs/archive/1.0/api/python/function.md
new file mode 100644
index 00000000000..1716c2b190b
--- /dev/null
+++ b/docs/archive/1.0/api/python/function.md
@@ -0,0 +1,232 @@
+---
+layout: docu
+title: Python Function API
+---
+
+You can create a DuckDB user-defined function (UDF) from a Python function so it can be used in SQL queries.
+Similarly to regular [functions]({% link docs/archive/1.0/sql/functions/overview.md %}), they need to have a name, a return type and parameter types.
+
+Here is an example using a Python function that calls a third-party library.
+
+```python
+import duckdb
+from duckdb.typing import *
+from faker import Faker
+
+def generate_random_name():
+ fake = Faker()
+ return fake.name()
+
+duckdb.create_function("random_name", generate_random_name, [], VARCHAR)
+res = duckdb.sql("SELECT random_name()").fetchall()
+print(res)
+```
+
+```text
+[('Gerald Ashley',)]
+```
+
+## Creating Functions
+
+To register a Python UDF, use the `create_function` method from a DuckDB connection. Here is the syntax:
+
+```python
+import duckdb
+con = duckdb.connect()
+con.create_function(name, function, parameters, return_type)
+```
+
+The `create_function` method takes the following parameters:
+
+1. **name**: A string representing the unique name of the UDF within the connection catalog.
+2. **function**: The Python function you wish to register as a UDF.
+3. **parameters**: Scalar functions can operate on one or more columns. This parameter takes a list of column types used as input.
+4. **return_type**: Scalar functions return one element per row. This parameter specifies the return type of the function.
+5. **type** (Optional): DuckDB supports both built-in Python types and PyArrow Tables. By default, built-in types are assumed, but you can specify `type = 'arrow'` to use PyArrow Tables.
+6. **null_handling** (Optional): By default, null values are automatically handled as Null-In Null-Out. Users can specify a desired behavior for null values by setting `null_handling = 'special'`.
+7. **exception_handling** (Optional): By default, when an exception is thrown from the Python function, it will be re-thrown in Python. Users can disable this behavior, and instead return `null`, by setting this parameter to `'return_null'`
+8. **side_effects** (Optional): By default, functions are expected to produce the same result for the same input. If the result of a function is impacted by any type of randomness, `side_effects` must be set to `True`.
+
+To unregister a UDF, you can call the `remove_function` method with the UDF name:
+
+```python
+con.remove_function(name)
+```
+
+## Type Annotation
+
+When the function has type annotation it's often possible to leave out all of the optional parameters.
+Using `DuckDBPyType` we can implicitly convert many known types to DuckDBs type system.
+For example:
+
+```python
+import duckdb
+
+def my_function(x: int) -> str:
+ return x
+
+duckdb.create_function("my_func", my_function)
+print(duckdb.sql("SELECT my_func(42)"))
+```
+
+```text
+┌─────────────┐
+│ my_func(42) │
+│ varchar │
+├─────────────┤
+│ 42 │
+└─────────────┘
+```
+
+If only the parameter list types can be inferred, you'll need to pass in `None` as `parameters`.
+
+## Null Handling
+
+By default when functions receive a `NULL` value, this instantly returns `NULL`, as part of the default `NULL`-handling.
+When this is not desired, you need to explicitly set this parameter to `"special"`.
+
+```python
+import duckdb
+from duckdb.typing import *
+
+def dont_intercept_null(x):
+ return 5
+
+duckdb.create_function("dont_intercept", dont_intercept_null, [BIGINT], BIGINT)
+res = duckdb.sql("SELECT dont_intercept(NULL)").fetchall()
+print(res)
+```
+
+```text
+[(None,)]
+```
+
+With `null_handling="special"`:
+
+```python
+import duckdb
+from duckdb.typing import *
+
+def dont_intercept_null(x):
+ return 5
+
+duckdb.create_function("dont_intercept", dont_intercept_null, [BIGINT], BIGINT, null_handling="special")
+res = duckdb.sql("SELECT dont_intercept(NULL)").fetchall()
+print(res)
+```
+
+```text
+[(5,)]
+```
+
+## Exception Handling
+
+By default, when an exception is thrown from the Python function, we'll forward (re-throw) the exception.
+If you want to disable this behavior, and instead return null, you'll need to set this parameter to `"return_null"`
+
+```python
+import duckdb
+from duckdb.typing import *
+
+def will_throw():
+ raise ValueError("ERROR")
+
+duckdb.create_function("throws", will_throw, [], BIGINT)
+try:
+ res = duckdb.sql("SELECT throws()").fetchall()
+except duckdb.InvalidInputException as e:
+ print(e)
+
+duckdb.create_function("doesnt_throw", will_throw, [], BIGINT, exception_handling="return_null")
+res = duckdb.sql("SELECT doesnt_throw()").fetchall()
+print(res)
+```
+
+```console
+Invalid Input Error: Python exception occurred while executing the UDF: ValueError: ERROR
+
+At:
+ ...(5): will_throw
+ ...(9): -
+
- +duckdb.threadsafety bool¶ + +
-
+
Indicates that this package is threadsafe
+
+
-
+
- +duckdb.apilevel int¶ + +
-
+
Indicates which Python DBAPI version this package implements
+
+
-
+
- +duckdb.paramstyle str¶ + +
-
+
Indicates which parameter style duckdb supports
+
+
-
+
- +duckdb.default_connection duckdb.DuckDBPyConnection¶ + +
-
+
The connection that is used by default if you don’t explicitly pass one to the root methods in this module
+
+
-
+
- +exception duckdb.BinderException¶ + +
-
+
Bases:
+ProgrammingError
+
-
+
- +duckdb.CaseExpression(condition: duckdb.duckdb.Expression, value: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + + +
-
+
- +exception duckdb.CatalogException¶ + +
-
+
Bases:
+ProgrammingError
+
-
+
- +duckdb.CoalesceOperator(*args) duckdb.duckdb.Expression¶ + + +
-
+
- +duckdb.ColumnExpression(name: str) duckdb.duckdb.Expression¶ + +
-
+
Create a column reference from the provided column name
+
+
-
+
- +exception duckdb.ConnectionException¶ + +
-
+
Bases:
+OperationalError
+
-
+
- +duckdb.ConstantExpression(value: object) duckdb.duckdb.Expression¶ + +
-
+
Create a constant expression from the provided value
+
+
-
+
- +exception duckdb.ConstraintException¶ + +
-
+
Bases:
+IntegrityError
+
-
+
- +exception duckdb.DataError¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +class duckdb.DuckDBPyConnection¶ + +
-
+
Bases:
+pybind11_object-
+
- +append(self: duckdb.duckdb.DuckDBPyConnection, table_name: str, df: pandas.DataFrame, *, by_name: bool = False) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Append the passed DataFrame to the named table
+
+
-
+
- +array_type(self: duckdb.duckdb.DuckDBPyConnection, type: duckdb.duckdb.typing.DuckDBPyType, size: int) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create an array type object of ‘type’
+
+
-
+
- +arrow(self: duckdb.duckdb.DuckDBPyConnection, rows_per_batch: int = 1000000) pyarrow.lib.Table¶ + +
-
+
Fetch a result as Arrow table following execute()
+
+
-
+
- +begin(self: duckdb.duckdb.DuckDBPyConnection) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Start a new transaction
+
+
-
+
- +checkpoint(self: duckdb.duckdb.DuckDBPyConnection) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Synchronizes data in the write-ahead log (WAL) to the database data file (no-op for in-memory connections)
+
+
-
+
- +close(self: duckdb.duckdb.DuckDBPyConnection) None¶ + +
-
+
Close the connection
+
+
-
+
- +commit(self: duckdb.duckdb.DuckDBPyConnection) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Commit changes performed within a transaction
+
+
-
+
- +create_function(self: duckdb.duckdb.DuckDBPyConnection, name: str, function: Callable, parameters: object = None, return_type: duckdb.duckdb.typing.DuckDBPyType = None, *, type: duckdb.duckdb.functional.PythonUDFType = <PythonUDFType.NATIVE: 0>, null_handling: duckdb.duckdb.functional.FunctionNullHandling = <FunctionNullHandling.DEFAULT: 0>, exception_handling: duckdb.duckdb.PythonExceptionHandling = <PythonExceptionHandling.DEFAULT: 0>, side_effects: bool = False) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Create a DuckDB function out of the passing in Python function so it can be used in queries
+
+
-
+
- +cursor(self: duckdb.duckdb.DuckDBPyConnection) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Create a duplicate of the current connection
+
+
-
+
- +decimal_type(self: duckdb.duckdb.DuckDBPyConnection, width: int, scale: int) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a decimal type with ‘width’ and ‘scale’
+
+
-
+
- +property description¶ + +
-
+
Get result set attributes, mainly column names
+
+
-
+
- +df(self: duckdb.duckdb.DuckDBPyConnection, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Fetch a result as DataFrame following execute()
+
+
-
+
- +dtype(self: duckdb.duckdb.DuckDBPyConnection, type_str: str) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a type object by parsing the ‘type_str’ string
+
+
-
+
- +duplicate(self: duckdb.duckdb.DuckDBPyConnection) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Create a duplicate of the current connection
+
+
-
+
- +enum_type(self: duckdb.duckdb.DuckDBPyConnection, name: str, type: duckdb.duckdb.typing.DuckDBPyType, values: list) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create an enum type of underlying ‘type’, consisting of the list of ‘values’
+
+
-
+
- +execute(self: duckdb.duckdb.DuckDBPyConnection, query: object, parameters: object = None, multiple_parameter_sets: bool = False) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Execute the given SQL query, optionally using prepared statements with parameters set
+
+
-
+
- +executemany(self: duckdb.duckdb.DuckDBPyConnection, query: object, parameters: object = None) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Execute the given prepared statement multiple times using the list of parameter sets in parameters
+
+
-
+
- +extract_statements(self: duckdb.duckdb.DuckDBPyConnection, query: str) list¶ + +
-
+
Parse the query string and extract the Statement object(s) produced
+
+
-
+
- +fetch_arrow_table(self: duckdb.duckdb.DuckDBPyConnection, rows_per_batch: int = 1000000) pyarrow.lib.Table¶ + +
-
+
Fetch a result as Arrow table following execute()
+
+
-
+
- +fetch_df(self: duckdb.duckdb.DuckDBPyConnection, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Fetch a result as DataFrame following execute()
+
+
-
+
- +fetch_df_chunk(self: duckdb.duckdb.DuckDBPyConnection, vectors_per_chunk: int = 1, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Fetch a chunk of the result as DataFrame following execute()
+
+
-
+
- +fetch_record_batch(self: duckdb.duckdb.DuckDBPyConnection, rows_per_batch: int = 1000000) pyarrow.lib.RecordBatchReader¶ + +
-
+
Fetch an Arrow RecordBatchReader following execute()
+
+
-
+
- +fetchall(self: duckdb.duckdb.DuckDBPyConnection) list¶ + +
-
+
Fetch all rows from a result following execute
+
+
-
+
- +fetchdf(self: duckdb.duckdb.DuckDBPyConnection, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Fetch a result as DataFrame following execute()
+
+
-
+
- +fetchmany(self: duckdb.duckdb.DuckDBPyConnection, size: int = 1) list¶ + +
-
+
Fetch the next set of rows from a result following execute
+
+
-
+
- +fetchnumpy(self: duckdb.duckdb.DuckDBPyConnection) dict¶ + +
-
+
Fetch a result as list of NumPy arrays following execute
+
+
-
+
- +fetchone(self: duckdb.duckdb.DuckDBPyConnection) Optional[tuple]¶ + +
-
+
Fetch a single row from a result following execute
+
+
-
+
- +filesystem_is_registered(self: duckdb.duckdb.DuckDBPyConnection, name: str) bool¶ + +
-
+
Check if a filesystem with the provided name is currently registered
+
+
-
+
- +from_arrow(self: duckdb.duckdb.DuckDBPyConnection, arrow_object: object) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object from an Arrow object
+
+
-
+
- +from_csv_auto(self: duckdb.duckdb.DuckDBPyConnection, path_or_buffer: object, *, header: object = None, compression: object = None, sep: object = None, delimiter: object = None, dtype: object = None, na_values: object = None, skiprows: object = None, quotechar: object = None, escapechar: object = None, encoding: object = None, parallel: object = None, date_format: object = None, timestamp_format: object = None, sample_size: object = None, all_varchar: object = None, normalize_names: object = None, filename: object = None, null_padding: object = None, names: object = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object from the CSV file in ‘name’
+
+
-
+
- +from_df(self: duckdb.duckdb.DuckDBPyConnection, df: pandas.DataFrame) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object from the DataFrame in df
+
+
-
+
- +from_parquet(*args, **kwargs)¶ + +
-
+
Overloaded function.
+-
+
from_parquet(self: duckdb.duckdb.DuckDBPyConnection, file_glob: str, binary_as_string: bool = False, *, file_row_number: bool = False, filename: bool = False, hive_partitioning: bool = False, union_by_name: bool = False, compression: object = None) -> duckdb.duckdb.DuckDBPyRelation
+
Create a relation object from the Parquet files in file_glob
+-
+
from_parquet(self: duckdb.duckdb.DuckDBPyConnection, file_globs: list[str], binary_as_string: bool = False, *, file_row_number: bool = False, filename: bool = False, hive_partitioning: bool = False, union_by_name: bool = False, compression: object = None) -> duckdb.duckdb.DuckDBPyRelation
+
Create a relation object from the Parquet files in file_globs
+
+
-
+
- +from_query(self: duckdb.duckdb.DuckDBPyConnection, query: object, *, alias: str = '', params: object = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Run a SQL query. If it is a SELECT statement, create a relation object from the given SQL query, otherwise run the query as-is.
+
+
-
+
- +from_substrait(self: duckdb.duckdb.DuckDBPyConnection, proto: bytes) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a query object from protobuf plan
+
+
-
+
- +from_substrait_json(self: duckdb.duckdb.DuckDBPyConnection, json: str) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a query object from a JSON protobuf plan
+
+
-
+
- +get_substrait(self: duckdb.duckdb.DuckDBPyConnection, query: str, *, enable_optimizer: bool = True) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Serialize a query to protobuf
+
+
-
+
- +get_substrait_json(self: duckdb.duckdb.DuckDBPyConnection, query: str, *, enable_optimizer: bool = True) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Serialize a query to protobuf on the JSON format
+
+
-
+
- +get_table_names(self: duckdb.duckdb.DuckDBPyConnection, query: str) set[str]¶ + +
-
+
Extract the required table names from a query
+
+
-
+
- +install_extension(self: duckdb.duckdb.DuckDBPyConnection, extension: str, *, force_install: bool = False) None¶ + +
-
+
Install an extension by name
+
+
-
+
- +interrupt(self: duckdb.duckdb.DuckDBPyConnection) None¶ + +
-
+
Interrupt pending operations
+
+
-
+
- +list_filesystems(self: duckdb.duckdb.DuckDBPyConnection) list¶ + +
-
+
List registered filesystems, including builtin ones
+
+
-
+
- +list_type(self: duckdb.duckdb.DuckDBPyConnection, type: duckdb.duckdb.typing.DuckDBPyType) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a list type object of ‘type’
+
+
-
+
- +load_extension(self: duckdb.duckdb.DuckDBPyConnection, extension: str) None¶ + +
-
+
Load an installed extension
+
+
-
+
- +map_type(self: duckdb.duckdb.DuckDBPyConnection, key: duckdb.duckdb.typing.DuckDBPyType, value: duckdb.duckdb.typing.DuckDBPyType) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a map type object from ‘key_type’ and ‘value_type’
+
+
-
+
- +pl(self: duckdb.duckdb.DuckDBPyConnection, rows_per_batch: int = 1000000) duckdb::PolarsDataFrame¶ + +
-
+
Fetch a result as Polars DataFrame following execute()
+
+
-
+
- +query(self: duckdb.duckdb.DuckDBPyConnection, query: object, *, alias: str = '', params: object = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Run a SQL query. If it is a SELECT statement, create a relation object from the given SQL query, otherwise run the query as-is.
+
+
-
+
- +read_csv(self: duckdb.duckdb.DuckDBPyConnection, path_or_buffer: object, *, header: object = None, compression: object = None, sep: object = None, delimiter: object = None, dtype: object = None, na_values: object = None, skiprows: object = None, quotechar: object = None, escapechar: object = None, encoding: object = None, parallel: object = None, date_format: object = None, timestamp_format: object = None, sample_size: object = None, all_varchar: object = None, normalize_names: object = None, filename: object = None, null_padding: object = None, names: object = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object from the CSV file in ‘name’
+
+
-
+
- +read_json(self: duckdb.duckdb.DuckDBPyConnection, name: str, *, columns: Optional[object] = None, sample_size: Optional[object] = None, maximum_depth: Optional[object] = None, records: Optional[str] = None, format: Optional[str] = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object from the JSON file in ‘name’
+
+
-
+
- +read_parquet(*args, **kwargs)¶ + +
-
+
Overloaded function.
+-
+
read_parquet(self: duckdb.duckdb.DuckDBPyConnection, file_glob: str, binary_as_string: bool = False, *, file_row_number: bool = False, filename: bool = False, hive_partitioning: bool = False, union_by_name: bool = False, compression: object = None) -> duckdb.duckdb.DuckDBPyRelation
+
Create a relation object from the Parquet files in file_glob
+-
+
read_parquet(self: duckdb.duckdb.DuckDBPyConnection, file_globs: list[str], binary_as_string: bool = False, *, file_row_number: bool = False, filename: bool = False, hive_partitioning: bool = False, union_by_name: bool = False, compression: object = None) -> duckdb.duckdb.DuckDBPyRelation
+
Create a relation object from the Parquet files in file_globs
+
+
-
+
- +register(self: duckdb.duckdb.DuckDBPyConnection, view_name: str, python_object: object) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Register the passed Python Object value for querying with a view
+
+
-
+
- +register_filesystem(self: duckdb.duckdb.DuckDBPyConnection, filesystem: fsspec.AbstractFileSystem) None¶ + +
-
+
Register a fsspec compliant filesystem
+
+
-
+
- +remove_function(self: duckdb.duckdb.DuckDBPyConnection, name: str) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Remove a previously created function
+
+
-
+
- +rollback(self: duckdb.duckdb.DuckDBPyConnection) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Roll back changes performed within a transaction
+
+
-
+
- +row_type(self: duckdb.duckdb.DuckDBPyConnection, fields: object) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a struct type object from ‘fields’
+
+
-
+
- +property rowcount¶ + +
-
+
Get result set row count
+
+
-
+
- +sql(self: duckdb.duckdb.DuckDBPyConnection, query: object, *, alias: str = '', params: object = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Run a SQL query. If it is a SELECT statement, create a relation object from the given SQL query, otherwise run the query as-is.
+
+
-
+
- +sqltype(self: duckdb.duckdb.DuckDBPyConnection, type_str: str) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a type object by parsing the ‘type_str’ string
+
+
-
+
- +string_type(self: duckdb.duckdb.DuckDBPyConnection, collation: str = '') duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a string type with an optional collation
+
+
-
+
- +struct_type(self: duckdb.duckdb.DuckDBPyConnection, fields: object) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a struct type object from ‘fields’
+
+
-
+
- +table(self: duckdb.duckdb.DuckDBPyConnection, table_name: str) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object for the named table
+
+
-
+
- +table_function(self: duckdb.duckdb.DuckDBPyConnection, name: str, parameters: object = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object from the named table function with given parameters
+
+
-
+
- +tf(self: duckdb.duckdb.DuckDBPyConnection) dict¶ + +
-
+
Fetch a result as dict of TensorFlow Tensors following execute()
+
+
-
+
- +torch(self: duckdb.duckdb.DuckDBPyConnection) dict¶ + +
-
+
Fetch a result as dict of PyTorch Tensors following execute()
+
+
-
+
- +type(self: duckdb.duckdb.DuckDBPyConnection, type_str: str) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a type object by parsing the ‘type_str’ string
+
+
-
+
- +union_type(self: duckdb.duckdb.DuckDBPyConnection, members: object) duckdb.duckdb.typing.DuckDBPyType¶ + +
-
+
Create a union type object from ‘members’
+
+
-
+
- +unregister(self: duckdb.duckdb.DuckDBPyConnection, view_name: str) duckdb.duckdb.DuckDBPyConnection¶ + +
-
+
Unregister the view name
+
+
-
+
- +unregister_filesystem(self: duckdb.duckdb.DuckDBPyConnection, name: str) None¶ + +
-
+
Unregister a filesystem
+
+
-
+
- +values(self: duckdb.duckdb.DuckDBPyConnection, values: object) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object from the passed values
+
+
-
+
- +view(self: duckdb.duckdb.DuckDBPyConnection, view_name: str) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create a relation object for the named view
+
+
+
-
+
- +class duckdb.DuckDBPyRelation¶ + +
-
+
Bases:
+pybind11_object-
+
- +aggregate(self: duckdb.duckdb.DuckDBPyRelation, aggr_expr: str, group_expr: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Compute the aggregate aggr_expr by the optional groups group_expr on the relation
+
+
-
+
- +property alias¶ + +
-
+
Get the name of the current alias
+
+
-
+
- +any_value(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Returns the first non-null value from a given column
+
+
-
+
- +apply(self: duckdb.duckdb.DuckDBPyRelation, function_name: str, function_aggr: str, group_expr: str = '', function_parameter: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Compute the function of a single column or a list of columns by the optional groups on the relation
+
+
-
+
- +arg_max(self: duckdb.duckdb.DuckDBPyRelation, arg_column: str, value_column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Finds the row with the maximum value for a value column and returns the value of that row for an argument column
+
+
-
+
- +arg_min(self: duckdb.duckdb.DuckDBPyRelation, arg_column: str, value_column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Finds the row with the minimum value for a value column and returns the value of that row for an argument column
+
+
-
+
- +arrow(self: duckdb.duckdb.DuckDBPyRelation, batch_size: int = 1000000) pyarrow.lib.Table¶ + +
-
+
Execute and fetch all rows as an Arrow Table
+
+
-
+
- +avg(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the average on a given column
+
+
-
+
- +bit_and(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the bitwise AND of all bits present in a given column
+
+
-
+
- +bit_or(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the bitwise OR of all bits present in a given column
+
+
-
+
- +bit_xor(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the bitwise XOR of all bits present in a given column
+
+
-
+
- +bitstring_agg(self: duckdb.duckdb.DuckDBPyRelation, column: str, min: Optional[object] = None, max: Optional[object] = None, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes a bitstring with bits set for each distinct value in a given column
+
+
-
+
- +bool_and(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the logical AND of all values present in a given column
+
+
-
+
- +bool_or(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the logical OR of all values present in a given column
+
+
-
+
- +close(self: duckdb.duckdb.DuckDBPyRelation) None¶ + +
-
+
Closes the result
+
+
-
+
- +property columns¶ + +
-
+
Return a list containing the names of the columns of the relation.
+
+
-
+
- +count(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the number of elements present in a given column
+
+
-
+
- +create(self: duckdb.duckdb.DuckDBPyRelation, table_name: str) None¶ + +
-
+
Creates a new table named table_name with the contents of the relation object
+
+
-
+
- +create_view(self: duckdb.duckdb.DuckDBPyRelation, view_name: str, replace: bool = True) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Creates a view named view_name that refers to the relation object
+
+
-
+
- +cume_dist(self: duckdb.duckdb.DuckDBPyRelation, window_spec: str, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the cumulative distribution within the partition
+
+
-
+
- +dense_rank(self: duckdb.duckdb.DuckDBPyRelation, window_spec: str, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the dense rank within the partition
+
+
-
+
- +describe(self: duckdb.duckdb.DuckDBPyRelation) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Gives basic statistics (e.g., min,max) and if null exists for each column of the relation.
+
+
-
+
- +property description¶ + +
-
+
Return the description of the result
+
+
-
+
- +df(self: duckdb.duckdb.DuckDBPyRelation, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Execute and fetch all rows as a pandas DataFrame
+
+
-
+
- +distinct(self: duckdb.duckdb.DuckDBPyRelation) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Retrieve distinct rows from this relation object
+
+
-
+
- +property dtypes¶ + +
-
+
Return a list containing the types of the columns of the relation.
+
+
-
+
- +except_(self: duckdb.duckdb.DuckDBPyRelation, other_rel: duckdb.duckdb.DuckDBPyRelation) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create the set except of this relation object with another relation object in other_rel
+
+
-
+
- +execute(self: duckdb.duckdb.DuckDBPyRelation) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Transform the relation into a result set
+
+
-
+
- +explain(self: duckdb.duckdb.DuckDBPyRelation, type: duckdb.duckdb.ExplainType = 'standard') str¶ + + +
-
+
- +favg(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the average of all values present in a given column using a more accurate floating point summation (Kahan Sum)
+
+
-
+
- +fetch_arrow_reader(self: duckdb.duckdb.DuckDBPyRelation, batch_size: int = 1000000) pyarrow.lib.RecordBatchReader¶ + +
-
+
Execute and return an Arrow Record Batch Reader that yields all rows
+
+
-
+
- +fetch_arrow_table(self: duckdb.duckdb.DuckDBPyRelation, batch_size: int = 1000000) pyarrow.lib.Table¶ + +
-
+
Execute and fetch all rows as an Arrow Table
+
+
-
+
- +fetch_df_chunk(self: duckdb.duckdb.DuckDBPyRelation, vectors_per_chunk: int = 1, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Execute and fetch a chunk of the rows
+
+
-
+
- +fetchall(self: duckdb.duckdb.DuckDBPyRelation) list¶ + +
-
+
Execute and fetch all rows as a list of tuples
+
+
-
+
- +fetchdf(self: duckdb.duckdb.DuckDBPyRelation, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Execute and fetch all rows as a pandas DataFrame
+
+
-
+
- +fetchmany(self: duckdb.duckdb.DuckDBPyRelation, size: int = 1) list¶ + +
-
+
Execute and fetch the next set of rows as a list of tuples
+
+
-
+
- +fetchnumpy(self: duckdb.duckdb.DuckDBPyRelation) dict¶ + +
-
+
Execute and fetch all rows as a Python dict mapping each column to one numpy arrays
+
+
-
+
- +fetchone(self: duckdb.duckdb.DuckDBPyRelation) Optional[tuple]¶ + +
-
+
Execute and fetch a single row as a tuple
+
+
-
+
- +filter(self: duckdb.duckdb.DuckDBPyRelation, filter_expr: object) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Filter the relation object by the filter in filter_expr
+
+
-
+
- +first(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Returns the first value of a given column
+
+
-
+
- +first_value(self: duckdb.duckdb.DuckDBPyRelation, column: str, window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the first value within the group or partition
+
+
-
+
- +fsum(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sum of all values present in a given column using a more accurate floating point summation (Kahan Sum)
+
+
-
+
- +geomean(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the geometric mean over all values present in a given column
+
+
-
+
- +histogram(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the histogram over all values present in a given column
+
+
-
+
- +insert(self: duckdb.duckdb.DuckDBPyRelation, values: object) None¶ + +
-
+
Inserts the given values into the relation
+
+
-
+
- +insert_into(self: duckdb.duckdb.DuckDBPyRelation, table_name: str) None¶ + +
-
+
Inserts the relation object into an existing table named table_name
+
+
-
+
- +intersect(self: duckdb.duckdb.DuckDBPyRelation, other_rel: duckdb.duckdb.DuckDBPyRelation) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create the set intersection of this relation object with another relation object in other_rel
+
+
-
+
- +join(self: duckdb.duckdb.DuckDBPyRelation, other_rel: duckdb.duckdb.DuckDBPyRelation, condition: object, how: str = 'inner') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Join the relation object with another relation object in other_rel using the join condition expression in join_condition. Types supported are ‘inner’ and ‘left’
+
+
-
+
- +lag(self: duckdb.duckdb.DuckDBPyRelation, column: str, window_spec: str, offset: int = 1, default_value: str = 'NULL', ignore_nulls: bool = False, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the lag within the partition
+
+
-
+
- +last(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Returns the last value of a given column
+
+
-
+
- +last_value(self: duckdb.duckdb.DuckDBPyRelation, column: str, window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the last value within the group or partition
+
+
-
+
- +lead(self: duckdb.duckdb.DuckDBPyRelation, column: str, window_spec: str, offset: int = 1, default_value: str = 'NULL', ignore_nulls: bool = False, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the lead within the partition
+
+
-
+
- +limit(self: duckdb.duckdb.DuckDBPyRelation, n: int, offset: int = 0) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Only retrieve the first n rows from this relation object, starting at offset
+
+
-
+
- +list(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Returns a list containing all values present in a given column
+
+
-
+
- +map(self: duckdb.duckdb.DuckDBPyRelation, map_function: Callable, *, schema: Optional[object] = None) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Calls the passed function on the relation
+
+
-
+
- +max(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Returns the maximum value present in a given column
+
+
-
+
- +mean(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the average on a given column
+
+
-
+
- +median(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the median over all values present in a given column
+
+
-
+
- +min(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Returns the minimum value present in a given column
+
+
-
+
- +mode(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the mode over all values present in a given column
+
+
-
+
- +n_tile(self: duckdb.duckdb.DuckDBPyRelation, window_spec: str, num_buckets: int, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Divides the partition as equally as possible into num_buckets
+
+
-
+
- +nth_value(self: duckdb.duckdb.DuckDBPyRelation, column: str, window_spec: str, offset: int, ignore_nulls: bool = False, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the nth value within the partition
+
+
-
+
- +order(self: duckdb.duckdb.DuckDBPyRelation, order_expr: str) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Reorder the relation object by order_expr
+
+
-
+
- +percent_rank(self: duckdb.duckdb.DuckDBPyRelation, window_spec: str, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the relative rank within the partition
+
+
-
+
- +pl(self: duckdb.duckdb.DuckDBPyRelation, batch_size: int = 1000000) duckdb::PolarsDataFrame¶ + +
-
+
Execute and fetch all rows as a Polars DataFrame
+
+
-
+
- +product(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Returns the product of all values present in a given column
+
+
-
+
- +project(self: duckdb.duckdb.DuckDBPyRelation, *args, **kwargs) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Project the relation object by the projection in project_expr
+
+
-
+
- +quantile(self: duckdb.duckdb.DuckDBPyRelation, column: str, q: object = 0.5, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the exact quantile value for a given column
+
+
-
+
- +quantile_cont(self: duckdb.duckdb.DuckDBPyRelation, column: str, q: object = 0.5, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the interpolated quantile value for a given column
+
+
-
+
- +quantile_disc(self: duckdb.duckdb.DuckDBPyRelation, column: str, q: object = 0.5, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the exact quantile value for a given column
+
+
-
+
- +query(self: duckdb.duckdb.DuckDBPyRelation, virtual_table_name: str, sql_query: str) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Run the given SQL query in sql_query on the view named virtual_table_name that refers to the relation object
+
+
-
+
- +rank(self: duckdb.duckdb.DuckDBPyRelation, window_spec: str, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the rank within the partition
+
+
-
+
- +rank_dense(self: duckdb.duckdb.DuckDBPyRelation, window_spec: str, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the dense rank within the partition
+
+
-
+
- +record_batch(self: duckdb.duckdb.DuckDBPyRelation, batch_size: int = 1000000) pyarrow.lib.RecordBatchReader¶ + +
-
+
Execute and return an Arrow Record Batch Reader that yields all rows
+
+
-
+
- +row_number(self: duckdb.duckdb.DuckDBPyRelation, window_spec: str, projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the row number within the partition
+
+
-
+
- +select(self: duckdb.duckdb.DuckDBPyRelation, *args, **kwargs) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Project the relation object by the projection in project_expr
+
+
-
+
- +select_dtypes(self: duckdb.duckdb.DuckDBPyRelation, types: object) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Select columns from the relation, by filtering based on type(s)
+
+
-
+
- +select_types(self: duckdb.duckdb.DuckDBPyRelation, types: object) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Select columns from the relation, by filtering based on type(s)
+
+
-
+
- +set_alias(self: duckdb.duckdb.DuckDBPyRelation, alias: str) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Rename the relation object to new alias
+
+
-
+
- +property shape¶ + +
-
+
Tuple of # of rows, # of columns in relation.
+
+
-
+
- +show(self: duckdb.duckdb.DuckDBPyRelation, *, max_width: Optional[int] = None, max_rows: Optional[int] = None, max_col_width: Optional[int] = None, null_value: Optional[str] = None, render_mode: object = None) None¶ + +
-
+
Display a summary of the data
+
+
-
+
- +sort(self: duckdb.duckdb.DuckDBPyRelation, *args) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Reorder the relation object by the provided expressions
+
+
-
+
- +sql_query(self: duckdb.duckdb.DuckDBPyRelation) str¶ + +
-
+
Get the SQL query that is equivalent to the relation
+
+
-
+
- +std(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sample standard deviation for a given column
+
+
-
+
- +stddev(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sample standard deviation for a given column
+
+
-
+
- +stddev_pop(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the population standard deviation for a given column
+
+
-
+
- +stddev_samp(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sample standard deviation for a given column
+
+
-
+
- +string_agg(self: duckdb.duckdb.DuckDBPyRelation, column: str, sep: str = ',', groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Concatenates the values present in a given column with a separator
+
+
-
+
- +sum(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sum of all values present in a given column
+
+
-
+
- +tf(self: duckdb.duckdb.DuckDBPyRelation) dict¶ + +
-
+
Fetch a result as dict of TensorFlow Tensors
+
+
-
+
- +to_arrow_table(self: duckdb.duckdb.DuckDBPyRelation, batch_size: int = 1000000) pyarrow.lib.Table¶ + +
-
+
Execute and fetch all rows as an Arrow Table
+
+
-
+
- +to_csv(self: duckdb.duckdb.DuckDBPyRelation, file_name: str, *, sep: object = None, na_rep: object = None, header: object = None, quotechar: object = None, escapechar: object = None, date_format: object = None, timestamp_format: object = None, quoting: object = None, encoding: object = None, compression: object = None, overwrite: object = None, per_thread_output: object = None, use_tmp_file: object = None, partition_by: object = None) None¶ + +
-
+
Write the relation object to a CSV file in ‘file_name’
+
+
-
+
- +to_df(self: duckdb.duckdb.DuckDBPyRelation, *, date_as_object: bool = False) pandas.DataFrame¶ + +
-
+
Execute and fetch all rows as a pandas DataFrame
+
+
-
+
- +to_parquet(self: duckdb.duckdb.DuckDBPyRelation, file_name: str, *, compression: object = None, field_ids: object = None, row_group_size_bytes: object = None, row_group_size: object = None) None¶ + +
-
+
Write the relation object to a Parquet file in ‘file_name’
+
+
-
+
- +to_table(self: duckdb.duckdb.DuckDBPyRelation, table_name: str) None¶ + +
-
+
Creates a new table named table_name with the contents of the relation object
+
+
-
+
- +to_view(self: duckdb.duckdb.DuckDBPyRelation, view_name: str, replace: bool = True) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Creates a view named view_name that refers to the relation object
+
+
-
+
- +torch(self: duckdb.duckdb.DuckDBPyRelation) dict¶ + +
-
+
Fetch a result as dict of PyTorch Tensors
+
+
-
+
- +property type¶ + +
-
+
Get the type of the relation.
+
+
-
+
- +property types¶ + +
-
+
Return a list containing the types of the columns of the relation.
+
+
-
+
- +union(self: duckdb.duckdb.DuckDBPyRelation, union_rel: duckdb.duckdb.DuckDBPyRelation) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Create the set union of this relation object with another relation object in other_rel
+
+
-
+
- +unique(self: duckdb.duckdb.DuckDBPyRelation, unique_aggr: str) duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Number of distinct values in a column.
+
+
-
+
- +value_counts(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the number of elements present in a given column, also projecting the original column
+
+
-
+
- +var(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sample variance for a given column
+
+
-
+
- +var_pop(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the population variance for a given column
+
+
-
+
- +var_samp(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sample variance for a given column
+
+
-
+
- +variance(self: duckdb.duckdb.DuckDBPyRelation, column: str, groups: str = '', window_spec: str = '', projected_columns: str = '') duckdb.duckdb.DuckDBPyRelation¶ + +
-
+
Computes the sample variance for a given column
+
+
-
+
- +write_csv(self: duckdb.duckdb.DuckDBPyRelation, file_name: str, *, sep: object = None, na_rep: object = None, header: object = None, quotechar: object = None, escapechar: object = None, date_format: object = None, timestamp_format: object = None, quoting: object = None, encoding: object = None, compression: object = None, overwrite: object = None, per_thread_output: object = None, use_tmp_file: object = None, partition_by: object = None) None¶ + +
-
+
Write the relation object to a CSV file in ‘file_name’
+
+
-
+
- +write_parquet(self: duckdb.duckdb.DuckDBPyRelation, file_name: str, *, compression: object = None, field_ids: object = None, row_group_size_bytes: object = None, row_group_size: object = None) None¶ + +
-
+
Write the relation object to a Parquet file in ‘file_name’
+
+
+
-
+
- +exception duckdb.Error¶ + +
-
+
Bases:
+Exception
+
-
+
- +class duckdb.ExplainType¶ + +
-
+
Bases:
+pybind11_objectMembers:
+STANDARD
+ANALYZE
+-
+
- +ANALYZE = <ExplainType.ANALYZE: 1>¶ + + +
-
+
- +STANDARD = <ExplainType.STANDARD: 0>¶ + + +
-
+
- +property name¶ + + +
-
+
- +property value¶ + + +
+
-
+
- +class duckdb.Expression¶ + +
-
+
Bases:
+pybind11_object-
+
- +alias(self: duckdb.duckdb.Expression, arg0: str) duckdb.duckdb.Expression¶ + +
-
+
Create a copy of this expression with the given alias.
+-
+
- Parameters: +
-
+
name: The alias to use for the expression, this will affect how it can be referenced.
+
+ - Returns: +
-
+
Expression: self with an alias.
+
+
+
-
+
- +asc(self: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Set the order by modifier to ASCENDING.
+
+
-
+
- +cast(self: duckdb.duckdb.Expression, type: duckdb.duckdb.typing.DuckDBPyType) duckdb.duckdb.Expression¶ + +
-
+
Create a CastExpression to type from self
+-
+
- Parameters: +
-
+
type: The type to cast to
+
+ - Returns: +
-
+
CastExpression: self::type
+
+
+
-
+
- +desc(self: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Set the order by modifier to DESCENDING.
+
+
-
+
- +isin(self: duckdb.duckdb.Expression, *args) duckdb.duckdb.Expression¶ + +
-
+
Return an IN expression comparing self to the input arguments.
+-
+
- Returns: +
-
+
DuckDBPyExpression: The compare IN expression
+
+
+
-
+
- +isnotin(self: duckdb.duckdb.Expression, *args) duckdb.duckdb.Expression¶ + +
-
+
Return a NOT IN expression comparing self to the input arguments.
+-
+
- Returns: +
-
+
DuckDBPyExpression: The compare NOT IN expression
+
+
+
-
+
- +isnotnull(self: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Create a binary IS NOT NULL expression from self
+-
+
- Returns: +
-
+
DuckDBPyExpression: self IS NOT NULL
+
+
+
-
+
- +isnull(self: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Create a binary IS NULL expression from self
+-
+
- Returns: +
-
+
DuckDBPyExpression: self IS NULL
+
+
+
-
+
- +nulls_first(self: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Set the NULL order by modifier to NULLS FIRST.
+
+
-
+
- +nulls_last(self: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Set the NULL order by modifier to NULLS LAST.
+
+
-
+
- +otherwise(self: duckdb.duckdb.Expression, value: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Add an ELSE <value> clause to the CaseExpression.
+-
+
- Parameters: +
-
+
value: The value to use if none of the WHEN conditions are met.
+
+ - Returns: +
-
+
CaseExpression: self with an ELSE clause.
+
+
+
-
+
- +show(self: duckdb.duckdb.Expression) None¶ + +
-
+
Print the stringified version of the expression.
+
+
-
+
- +when(self: duckdb.duckdb.Expression, condition: duckdb.duckdb.Expression, value: duckdb.duckdb.Expression) duckdb.duckdb.Expression¶ + +
-
+
Add an additional WHEN <condition> THEN <value> clause to the CaseExpression.
+-
+
- Parameters: +
-
+
condition: The condition that must be met. +value: The value to use if the condition is met.
+
+ - Returns: +
-
+
CaseExpression: self with an additional WHEN clause.
+
+
+
+
-
+
- +exception duckdb.FatalException¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +duckdb.FunctionExpression(function_name: str, *args) duckdb.duckdb.Expression¶ + + +
-
+
- +exception duckdb.HTTPException¶ + +
-
+
Bases:
+IOExceptionThrown when an error occurs in the httpfs extension, or whilst downloading an extension.
+-
+
- +body: str¶ + + +
-
+
- +headers: Dict[str, str]¶ + + +
-
+
- +reason: str¶ + + +
-
+
- +status_code: int¶ + + +
+
-
+
- +exception duckdb.IOException¶ + +
-
+
Bases:
+OperationalError
+
-
+
- +exception duckdb.IntegrityError¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +exception duckdb.InternalError¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +exception duckdb.InternalException¶ + +
-
+
Bases:
+InternalError
+
-
+
- +exception duckdb.InterruptException¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +exception duckdb.InvalidInputException¶ + +
-
+
Bases:
+ProgrammingError
+
-
+
- +exception duckdb.InvalidTypeException¶ + +
-
+
Bases:
+ProgrammingError
+
-
+
- +exception duckdb.NotImplementedException¶ + +
-
+
Bases:
+NotSupportedError
+
-
+
- +exception duckdb.NotSupportedError¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +exception duckdb.OperationalError¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +exception duckdb.OutOfMemoryException¶ + +
-
+
Bases:
+OperationalError
+
-
+
- +exception duckdb.ParserException¶ + +
-
+
Bases:
+ProgrammingError
+
-
+
- +exception duckdb.PermissionException¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +exception duckdb.ProgrammingError¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +class duckdb.PythonExceptionHandling¶ + +
-
+
Bases:
+pybind11_objectMembers:
+DEFAULT
+RETURN_NULL
+-
+
- +DEFAULT = <PythonExceptionHandling.DEFAULT: 0>¶ + + +
-
+
- +RETURN_NULL = <PythonExceptionHandling.RETURN_NULL: 1>¶ + + +
-
+
- +property name¶ + + +
-
+
- +property value¶ + + +
+
-
+
- +exception duckdb.SequenceException¶ + +
-
+
Bases:
+DatabaseError
+
-
+
- +exception duckdb.SerializationException¶ + +
-
+
Bases:
+OperationalError
+
-
+
- +duckdb.StarExpression(*args, **kwargs)¶ + +
-
+
Overloaded function.
+-
+
StarExpression(*, exclude: list = []) -> duckdb.duckdb.Expression
+StarExpression() -> duckdb.duckdb.Expression
+
+
-
+
- +exception duckdb.SyntaxException¶ + +
-
+
Bases:
+ProgrammingError
+
-
+
- +exception duckdb.TransactionException¶ + +
-
+
Bases:
+OperationalError
+
-
+
- +class duckdb.Value(object: Any, type: DuckDBPyType)¶ + +
-
+
Bases:
+object
+
-
+
- +exception duckdb.Warning¶ + +
-
+
Bases:
+Exception
+
-
+
- +duckdb.aggregate(df, aggr_expr, group_expr='', **kwargs)¶ + + +
-
+
- +duckdb.alias(df, alias, **kwargs)¶ + + +
-
+
- +duckdb.append(table_name, df, **kwargs)¶ + + +
-
+
- +duckdb.array_type(type, size, **kwargs)¶ + + +
-
+
- +duckdb.arrow(*args, **kwargs)¶ + +
-
+
Overloaded function.
+-
+
arrow(rows_per_batch: int = 1000000, *, connection: duckdb.DuckDBPyConnection = None) -> pyarrow.lib.Table
+
Fetch a result as Arrow table following execute()
+-
+
arrow(arrow_object: object, *, connection: duckdb.DuckDBPyConnection = None) -> duckdb.duckdb.DuckDBPyRelation
+
Create a relation object from an Arrow object
+
+
-
+
- +duckdb.begin(**kwargs)¶ + + +
-
+
- +duckdb.checkpoint(**kwargs)¶ + + +
-
+
- +duckdb.close(**kwargs)¶ + + +
-
+
- +duckdb.commit(**kwargs)¶ + + +
-
+
- +duckdb.connect(database: str = ':memory:', read_only: bool = False, config: dict = None) duckdb.DuckDBPyConnection¶ + +
-
+
Create a DuckDB database instance. Can take a database file name to read/write persistent data and a read_only flag if no changes are desired
+
+
-
+
- +duckdb.create_function(name, function, parameters=None, return_type=None, **kwargs)¶ + + +
-
+
- +duckdb.cursor(**kwargs)¶ + + +
-
+
- +duckdb.decimal_type(width, scale, **kwargs)¶ + + +
-
+
- +duckdb.description(**kwargs)¶ + + +
-
+
- +duckdb.df(*args, **kwargs)¶ + +
-
+
Overloaded function.
+-
+
df(*, date_as_object: bool = False, connection: duckdb.DuckDBPyConnection = None) -> pandas.DataFrame
+
Fetch a result as DataFrame following execute()
+-
+
df(df: pandas.DataFrame, *, connection: duckdb.DuckDBPyConnection = None) -> duckdb.duckdb.DuckDBPyRelation
+
Create a relation object from the DataFrame df
+
+
-
+
- +duckdb.distinct(df, **kwargs)¶ + + +
-
+
- +duckdb.dtype(type_str, **kwargs)¶ + + +
-
+
- +duckdb.duplicate(**kwargs)¶ + + +
-
+
- +duckdb.enum_type(name, type, values, **kwargs)¶ + + +
-
+
- +duckdb.execute(query, parameters=None, multiple_parameter_sets=False, **kwargs)¶ + + +
-
+
- +duckdb.executemany(query, parameters=None, **kwargs)¶ + + +
-
+
- +duckdb.extract_statements(query, **kwargs)¶ + + +
-
+
- +duckdb.fetch_arrow_table(rows_per_batch=1000000, **kwargs)¶ + + +
-
+
- +duckdb.fetch_df(**kwargs)¶ + + +
-
+
- +duckdb.fetch_df_chunk(vectors_per_chunk=1, **kwargs)¶ + + +
-
+
- +duckdb.fetch_record_batch(rows_per_batch=1000000, **kwargs)¶ + + +
-
+
- +duckdb.fetchall(**kwargs)¶ + + +
-
+
- +duckdb.fetchdf(**kwargs)¶ + + +
-
+
- +duckdb.fetchmany(size=1, **kwargs)¶ + + +
-
+
- +duckdb.fetchnumpy(**kwargs)¶ + + +
-
+
- +duckdb.fetchone(**kwargs)¶ + + +
-
+
- +duckdb.filesystem_is_registered(name, **kwargs)¶ + + +
-
+
- +duckdb.filter(df, filter_expr, **kwargs)¶ + + +
-
+
- +duckdb.from_arrow(arrow_object, **kwargs)¶ + + +
-
+
- +duckdb.from_csv_auto(path_or_buffer, **kwargs)¶ + + +
-
+
- +duckdb.from_df(df, **kwargs)¶ + + +
-
+
- +duckdb.from_parquet(file_glob, binary_as_string=False, **kwargs)¶ + + +
-
+
- +duckdb.from_query(query, **kwargs)¶ + + +
-
+
- +duckdb.from_substrait(proto, **kwargs)¶ + + +
-
+
- +duckdb.from_substrait_json(json, **kwargs)¶ + + +
-
+
- +duckdb.get_substrait(query, **kwargs)¶ + + +
-
+
- +duckdb.get_substrait_json(query, **kwargs)¶ + + +
-
+
- +duckdb.get_table_names(query, **kwargs)¶ + + +
-
+
- +duckdb.install_extension(extension, **kwargs)¶ + + +
-
+
- +duckdb.interrupt(**kwargs)¶ + + +
-
+
- +duckdb.limit(df, n, offset=0, **kwargs)¶ + + +
-
+
- +duckdb.list_filesystems(**kwargs)¶ + + +
-
+
- +duckdb.list_type(type, **kwargs)¶ + + +
-
+
- +duckdb.load_extension(extension, **kwargs)¶ + + +
-
+
- +duckdb.map_type(key, value, **kwargs)¶ + + +
-
+
- +duckdb.order(df, order_expr, **kwargs)¶ + + +
-
+
- +duckdb.pl(rows_per_batch=1000000, **kwargs)¶ + + +
-
+
- +duckdb.project(df, project_expr, **kwargs)¶ + + +
-
+
- +duckdb.query(query, **kwargs)¶ + + +
-
+
- +duckdb.query_df(df, virtual_table_name, sql_query, **kwargs)¶ + + +
-
+
- +duckdb.read_csv(path_or_buffer, **kwargs)¶ + + +
-
+
- +duckdb.read_json(name, **kwargs)¶ + + +
-
+
- +duckdb.read_parquet(file_glob, binary_as_string=False, **kwargs)¶ + + +
-
+
- +duckdb.register(view_name, python_object, **kwargs)¶ + + +
-
+
- +duckdb.register_filesystem(filesystem, **kwargs)¶ + + +
-
+
- +duckdb.remove_function(name, **kwargs)¶ + + +
-
+
- +duckdb.rollback(**kwargs)¶ + + +
-
+
- +duckdb.row_type(fields, **kwargs)¶ + + +
-
+
- +duckdb.rowcount(**kwargs)¶ + + +
-
+
- +duckdb.sql(query, **kwargs)¶ + + +
-
+
- +duckdb.sqltype(type_str, **kwargs)¶ + + +
-
+
- +duckdb.string_type(collation='', **kwargs)¶ + + +
-
+
- +duckdb.struct_type(fields, **kwargs)¶ + + +
-
+
- +duckdb.table(table_name, **kwargs)¶ + + +
-
+
- +duckdb.table_function(name, parameters=None, **kwargs)¶ + + +
-
+
- +duckdb.tf(**kwargs)¶ + + +
-
+
- +class duckdb.token_type¶ + +
-
+
Bases:
+pybind11_objectMembers:
+identifier
+numeric_const
+string_const
+operator
+keyword
+comment
+-
+
- +comment = <token_type.comment: 5>¶ + + +
-
+
- +identifier = <token_type.identifier: 0>¶ + + +
-
+
- +keyword = <token_type.keyword: 4>¶ + + +
-
+
- +property name¶ + + +
-
+
- +numeric_const = <token_type.numeric_const: 1>¶ + + +
-
+
- +operator = <token_type.operator: 3>¶ + + +
-
+
- +string_const = <token_type.string_const: 2>¶ + + +
-
+
- +property value¶ + + +
+
-
+
- +duckdb.tokenize(query: str) list¶ + +
-
+
Tokenizes a SQL string, returning a list of (position, type) tuples that can be used for e.g. syntax highlighting
+
+
-
+
- +duckdb.torch(**kwargs)¶ + + +
-
+
- +duckdb.type(type_str, **kwargs)¶ + + +
-
+
- +duckdb.union_type(members, **kwargs)¶ + + +
-
+
- +duckdb.unregister(view_name, **kwargs)¶ + + +
-
+
- +duckdb.unregister_filesystem(name, **kwargs)¶ + + +
-
+
- +duckdb.values(values, **kwargs)¶ + + +
-
+
- +duckdb.view(view_name, **kwargs)¶ + + +
-
+
- +duckdb.write_csv(df, *args, **kwargs)¶ + + +
+ 
+
+3. Search for DuckDB, select it, and click Next.
+
+ 
+
+4. Enter the path or browse to the DuckDB database file you wish to query. To use an in-memory DuckDB (useful primarily if just interested in querying Parquet files, or for testing) enter `:memory:` as the path.
+
+ 
+
+5. Click “Test Connection”. This will then prompt you to install the DuckDB JDBC driver. If you are not prompted, see alternative driver installation instructions below.
+
+ 
+
+6. Click “Download” to download DuckDB's JDBC driver from Maven. Once download is complete, click “OK”, then click “Finish”.
+* Note: If you are in a corporate environment or behind a firewall, before clicking download, click the “Download Configuration” link to configure your proxy settings.
+
+ 
+
+7. You should now see a database connection to your DuckDB database in the left hand “Database Navigator” pane. Expand it to see the tables and views in your database. Right click on that connection and create a new SQL script.
+
+ 
+
+8. Write some SQL and click the “Execute” button.
+
+ 
+
+9. Now you're ready to fly with DuckDB and DBeaver!
+
+ 
+
+## Alternative Driver Installation
+
+1. If not prompted to install the DuckDB driver when testing your connection, return to the “Connect to a database” dialog and click “Edit Driver Settings”.
+
+ 
+
+2. (Alternate) You may also access the driver settings menu by returning to the main DBeaver window and clicking Database > Driver Manager in the menu bar. Then select DuckDB, then click Edit.
+
+ 
+ 
+
+3. Go to the “Libraries” tab, then click on the DuckDB driver and click “Download/Update”. If you do not see the DuckDB driver, first click on “Reset to Defaults”.
+
+ 
+
+4. Click “Download” to download DuckDB's JDBC driver from Maven. Once download is complete, click “OK”, then return to the main DBeaver window and continue with step 7 above.
+
+ * Note: If you are in a corporate environment or behind a firewall, before clicking download, click the “Download Configuration” link to configure your proxy settings.
+
+ 
\ No newline at end of file
diff --git a/docs/archive/1.0/guides/sql_features/asof_join.md b/docs/archive/1.0/guides/sql_features/asof_join.md
new file mode 100644
index 00000000000..93b3d402cd4
--- /dev/null
+++ b/docs/archive/1.0/guides/sql_features/asof_join.md
@@ -0,0 +1,174 @@
+---
+layout: docu
+title: AsOf Join
+---
+
+## What is an AsOf Join?
+
+Time series data is not always perfectly aligned.
+Clocks may be slightly off, or there may be a delay between cause and effect.
+This can make connecting two sets of ordered data challenging.
+AsOf joins are a tool for solving this and other similar problems.
+
+One of the problems that AsOf joins are used to solve is
+finding the value of a varying property at a specific point in time.
+This use case is so common that it is where the name came from:
+
+_Give me the value of the property **as of this time**_.
+
+More generally, however, AsOf joins embody some common temporal analytic semantics,
+which can be cumbersome and slow to implement in standard SQL.
+
+## Portfolio Example Data Set
+
+Let's start with a concrete example.
+Suppose we have a table of stock [`prices`](/data/prices.csv) with timestamps:
+
+
+
+| ticker | when | price |
+| :----- | :--- | ----: |
+| APPL | 2001-01-01 00:00:00 | 1 |
+| APPL | 2001-01-01 00:01:00 | 2 |
+| APPL | 2001-01-01 00:02:00 | 3 |
+| MSFT | 2001-01-01 00:00:00 | 1 |
+| MSFT | 2001-01-01 00:01:00 | 2 |
+| MSFT | 2001-01-01 00:02:00 | 3 |
+| GOOG | 2001-01-01 00:00:00 | 1 |
+| GOOG | 2001-01-01 00:01:00 | 2 |
+| GOOG | 2001-01-01 00:02:00 | 3 |
+
+We have another table containing portfolio [`holdings`](/data/holdings.csv) at various points in time:
+
+
+
+| ticker | when | shares |
+| :----- | :--- | -----: |
+| APPL | 2000-12-31 23:59:30 | 5.16 |
+| APPL | 2001-01-01 00:00:30 | 2.94 |
+| APPL | 2001-01-01 00:01:30 | 24.13 |
+| GOOG | 2000-12-31 23:59:30 | 9.33 |
+| GOOG | 2001-01-01 00:00:30 | 23.45 |
+| GOOG | 2001-01-01 00:01:30 | 10.58 |
+| DATA | 2000-12-31 23:59:30 | 6.65 |
+| DATA | 2001-01-01 00:00:30 | 17.95 |
+| DATA | 2001-01-01 00:01:30 | 18.37 |
+
+To load these tables to DuckDB, run:
+
+```sql
+CREATE TABLE prices AS FROM 'https://duckdb.org/data/prices.csv';
+CREATE TABLE holdings AS FROM 'https://duckdb.org/data/holdings.csv';
+```
+
+## Inner AsOf Joins
+
+We can compute the value of each holding at that point in time by finding
+the most recent price before the holding's timestamp by using an AsOf Join:
+
+```sql
+SELECT h.ticker, h.when, price * shares AS value
+FROM holdings h
+ASOF JOIN prices p
+ ON h.ticker = p.ticker
+ AND h.when >= p.when;
+```
+
+This attaches the value of the holding at that time to each row:
+
+
+
+| ticker | when | value |
+| :----- | :--- | ----: |
+| APPL | 2001-01-01 00:00:30 | 2.94 |
+| APPL | 2001-01-01 00:01:30 | 48.26 |
+| GOOG | 2001-01-01 00:00:30 | 23.45 |
+| GOOG | 2001-01-01 00:01:30 | 21.16 |
+
+It essentially executes a function defined by looking up nearby values in the `prices` table.
+Note also that missing `ticker` values do not have a match and don't appear in the output.
+
+## Outer AsOf Joins
+
+Because AsOf produces at most one match from the right hand side,
+the left side table will not grow as a result of the join,
+but it could shrink if there are missing times on the right.
+To handle this situation, you can use an *outer* AsOf Join:
+
+```sql
+SELECT h.ticker, h.when, price * shares AS value
+FROM holdings h
+ASOF LEFT JOIN prices p
+ ON h.ticker = p.ticker
+ AND h.when >= p.when
+ORDER BY ALL;
+```
+
+As you might expect, this will produce `NULL` prices and values instead of dropping left side rows
+when there is no ticker or the time is before the prices begin.
+
+
+
+| ticker | when | value |
+| :----- | :--- | ----: |
+| APPL | 2000-12-31 23:59:30 | |
+| APPL | 2001-01-01 00:00:30 | 2.94 |
+| APPL | 2001-01-01 00:01:30 | 48.26 |
+| GOOG | 2000-12-31 23:59:30 | |
+| GOOG | 2001-01-01 00:00:30 | 23.45 |
+| GOOG | 2001-01-01 00:01:30 | 21.16 |
+| DATA | 2000-12-31 23:59:30 | |
+| DATA | 2001-01-01 00:00:30 | |
+| DATA | 2001-01-01 00:01:30 | |
+
+## AsOf Joins with the `USING` Keyword
+
+So far we have been explicit about specifying the conditions for AsOf,
+but SQL also has a simplified join condition syntax
+for the common case where the column names are the same in both tables.
+This syntax uses the `USING` keyword to list the fields that should be compared for equality.
+AsOf also supports this syntax, but with two restrictions:
+
+* The last field is the inequality
+* The inequality is `>=` (the most common case)
+
+Our first query can then be written as:
+
+```sql
+SELECT ticker, h.when, price * shares AS value
+FROM holdings h
+ASOF JOIN prices p USING (ticker, "when");
+```
+
+### Clarification on Column Selection with `USING` in ASOF Joins
+
+When you use the `USING` keyword in a join, the columns specified in the `USING` clause are merged in the result set. This means that if you run:
+
+```sql
+SELECT *
+FROM holdings h
+ASOF JOIN prices p USING (ticker, "when");
+```
+
+You will get back only the columns `h.ticker, h.when, h.shares, p.price`. The columns `ticker` and `when` will appear only once, with `ticker`
+and `when` coming from the left table (holdings).
+
+This behavior is fine for the `ticker` column because the value is the same in both tables. However, for the `when` column, the values might
+differ between the two tables due to the `>=` condition used in the AsOf join. The AsOf join is designed to match each row in the left
+table (`holdings`) with the nearest preceding row in the right table (`prices`) based on the `when` column.
+
+If you want to retrieve the `when` column from both tables to see both timestamps, you need to list the columns explicitly rather than
+relying on `*`, like so:
+
+```sql
+SELECT h.ticker, h.when AS holdings_when, p.when AS prices_when, h.shares, p.price
+FROM holdings h
+ASOF JOIN prices p USING (ticker, "when");
+```
+
+This ensures that you get the complete information from both tables, avoiding any potential confusion caused by the default behavior of
+the `USING` keyword.
+
+## See Also
+
+For implementation details, see the [blog post “DuckDB's AsOf joins: Fuzzy Temporal Lookups”](/2023/09/15/asof-joins-fuzzy-temporal-lookups).
\ No newline at end of file
diff --git a/docs/archive/1.0/guides/sql_features/full_text_search.md b/docs/archive/1.0/guides/sql_features/full_text_search.md
new file mode 100644
index 00000000000..e838e79d0e6
--- /dev/null
+++ b/docs/archive/1.0/guides/sql_features/full_text_search.md
@@ -0,0 +1,77 @@
+---
+layout: docu
+title: Full-Text Search
+---
+
+DuckDB supports full-text search via the [`fts` extension]({% link docs/archive/1.0/extensions/full_text_search.md %}).
+A full-text index allows for a query to quickly search for all occurrences of individual words within longer text strings.
+
+## Example: Shakespeare Corpus
+
+Here's an example of building a full-text index of Shakespeare's plays.
+
+```sql
+CREATE TABLE corpus AS
+ SELECT * FROM 'https://blobs.duckdb.org/data/shakespeare.parquet';
+```
+
+```sql
+DESCRIBE corpus;
+```
+
+| column_name | column_type | null | key | default | extra |
+|-------------|-------------|------|------|---------|-------|
+| line_id | VARCHAR | YES | NULL | NULL | NULL |
+| play_name | VARCHAR | YES | NULL | NULL | NULL |
+| line_number | VARCHAR | YES | NULL | NULL | NULL |
+| speaker | VARCHAR | YES | NULL | NULL | NULL |
+| text_entry | VARCHAR | YES | NULL | NULL | NULL |
+
+The text of each line is in `text_entry`, and a unique key for each line is in `line_id`.
+
+## Creating a Full-Text Search Index
+
+First, we create the index, specifying the table name, the unique id column, and the column(s) to index. We will just index the single column `text_entry`, which contains the text of the lines in the play.
+
+```sql
+PRAGMA create_fts_index('corpus', 'line_id', 'text_entry');
+```
+
+The table is now ready to query using the [Okapi BM25](https://en.wikipedia.org/wiki/Okapi_BM25) ranking function. Rows with no match return a null score.
+
+What does Shakespeare say about butter?
+
+```sql
+SELECT
+ fts_main_corpus.match_bm25(line_id, 'butter') AS score,
+ line_id, play_name, speaker, text_entry
+FROM corpus
+WHERE score IS NOT NULL
+ORDER BY score DESC;
+```
+
+| score | line_id | play_name | speaker | text_entry |
+|-------------------:|-------------|--------------------------|--------------|----------------------------------------------------|
+| 4.427313429798464 | H4/2.4.494 | Henry IV | Carrier | As fat as butter. |
+| 3.836270302568675 | H4/1.2.21 | Henry IV | FALSTAFF | prologue to an egg and butter. |
+| 3.836270302568675 | H4/2.1.55 | Henry IV | Chamberlain | They are up already, and call for eggs and butter; |
+| 3.3844488405497115 | H4/4.2.21 | Henry IV | FALSTAFF | toasts-and-butter, with hearts in their bellies no |
+| 3.3844488405497115 | H4/4.2.62 | Henry IV | PRINCE HENRY | already made thee butter. But tell me, Jack, whose |
+| 3.3844488405497115 | AWW/4.1.40 | Alls well that ends well | PAROLLES | butter-womans mouth and buy myself another of |
+| 3.3844488405497115 | AYLI/3.2.93 | As you like it | TOUCHSTONE | right butter-womens rank to market. |
+| 3.3844488405497115 | KL/2.4.132 | King Lear | Fool | kindness to his horse, buttered his hay. |
+| 3.0278411214953107 | AWW/5.2.9 | Alls well that ends well | Clown | henceforth eat no fish of fortunes buttering. |
+| 3.0278411214953107 | MWW/2.2.260 | Merry Wives of Windsor | FALSTAFF | Hang him, mechanical salt-butter rogue! I will |
+| 3.0278411214953107 | MWW/2.2.284 | Merry Wives of Windsor | FORD | rather trust a Fleming with my butter, Parson Hugh |
+| 3.0278411214953107 | MWW/3.5.7 | Merry Wives of Windsor | FALSTAFF | Ill have my brains taen out and buttered, and give |
+| 3.0278411214953107 | MWW/3.5.102 | Merry Wives of Windsor | FALSTAFF | to heat as butter; a man of continual dissolution |
+| 2.739219044070792 | H4/2.4.115 | Henry IV | PRINCE HENRY | Didst thou never see Titan kiss a dish of butter? |
+
+Unlike standard indexes, full-text indexes don't auto-update as the underlying data is changed, so you need to `PRAGMA drop_fts_index(my_fts_index)` and recreate it when appropriate.
+
+## Note on Generating the Corpus Table
+
+For more details, see the [“Generating a Shakespeare corpus for full-text searching from JSON” blog post](https://duckdb.blogspot.com/2023/04/generating-shakespeare-corpus-for-full.html)
+* The Columns are: line_id, play_name, line_number, speaker, text_entry.
+* We need a unique key for each row in order for full-text searching to work.
+* The line_id `KL/2.4.132` means King Lear, Act 2, Scene 4, Line 132.
\ No newline at end of file
diff --git a/docs/archive/1.0/index.md b/docs/archive/1.0/index.md
new file mode 100644
index 00000000000..e927bf4d972
--- /dev/null
+++ b/docs/archive/1.0/index.md
@@ -0,0 +1,22 @@
+---
+layout: docu
+title: Documentation
+---
+
+Welcome to the DuckDB documentation!
+
+* [DuckDB connection overview]({% link docs/archive/1.0/connect/overview.md %})
+* Client APIs
+ * [CLI (command line interface)]({% link docs/archive/1.0/api/cli/overview.md %})
+ * [Java]({% link docs/archive/1.0/api/java.md %})
+ * [Python]({% link docs/archive/1.0/api/python/overview.md %})
+ * [R]({% link docs/archive/1.0/api/r.md %})
+ * [WebAssembly]({% link docs/archive/1.0/api/wasm/overview.md %})
+ * see all [client APIs]({% link docs/archive/1.0/api/overview.md %})
+* SQL
+ * [Introduction]({% link docs/archive/1.0/sql/introduction.md %})
+ * [Statements]({% link docs/archive/1.0/sql/statements/overview.md %})
+* [Guides]({% link docs/archive/1.0/guides/overview.md %})
+* [Installation]({% link docs/archive/1.0/installation/index.html %})
+
+You can also [browse the DuckDB documentation offline]({% link docs/archive/1.0/guides/offline-copy.md %}).
\ No newline at end of file
diff --git a/docs/archive/1.0/installation/index.html b/docs/archive/1.0/installation/index.html
new file mode 100644
index 00000000000..be26b86d1e9
--- /dev/null
+++ b/docs/archive/1.0/installation/index.html
@@ -0,0 +1,110 @@
+---
+body_class: installation
+excerpt: DuckDB installation page
+layout: docu
+title: DuckDB Installation
+---
+
+
+### Constant Vectors
+
+Constant vectors are physically stored as a single constant value.
+
+
+
+Constant vectors are useful when data elements are repeated – for example, when representing the result of a constant expression in a function call, the constant vector allows us to only store the value once.
+
+```sql
+SELECT lst || 'duckdb'
+FROM range(1000) tbl(lst);
+```
+
+Since `duckdb` is a string literal, the value of the literal is the same for every row. In a flat vector, we would have to duplicate the literal 'duckdb' once for every row. The constant vector allows us to only store the literal once.
+
+Constant vectors are also emitted by the storage when decompressing from constant compression.
+
+### Dictionary Vectors
+
+Dictionary vectors are physically stored as a child vector, and a selection vector that contains indexes into the child vector.
+
+
+
+Dictionary vectors are emitted by the storage when decompressing from dictionary
+
+Just like constant vectors, dictionary vectors are also emitted by the storage.
+When deserializing a dictionary compressed column segment, we store this in a dictionary vector so we can keep the data compressed during query execution.
+
+### Sequence Vectors
+
+Sequence vectors are physically stored as an offset and an increment value.
+
+
+
+Sequence vectors are useful for efficiently storing incremental sequences. They are generally emitted for row identifiers.
+
+### Unified Vector Format
+
+These properties of the different vector formats are great for optimization purposes, for example you can imagine the scenario where all the parameters to a function are constant, we can just compute the result once and emit a constant vector.
+But writing specialized code for every combination of vector types for every function is unfeasible due to the combinatorial explosion of possibilities.
+
+Instead of doing this, whenever you want to generically use a vector regardless of the type, the UnifiedVectorFormat can be used.
+This format essentially acts as a generic view over the contents of the Vector. Every type of Vector can convert to this format.
+
+## Complex Types
+
+### String Vectors
+
+To efficiently store strings, we make use of our `string_t` class.
+
+```cpp
+struct string_t {
+ union {
+ struct {
+ uint32_t length;
+ char prefix[4];
+ char *ptr;
+ } pointer;
+ struct {
+ uint32_t length;
+ char inlined[12];
+ } inlined;
+ } value;
+};
+```
+
+Short strings (`<= 12 bytes`) are inlined into the structure, while larger strings are stored with a pointer to the data in the auxiliary string buffer. The length is used throughout the functions to avoid having to call `strlen` and having to continuously check for null-pointers. The prefix is used for comparisons as an early out (when the prefix does not match, we know the strings are not equal and don't need to chase any pointers).
+
+### List Vectors
+
+List vectors are stored as a series of *list entries* together with a child Vector. The child vector contains the *values* that are present in the list, and the list entries specify how each individual list is constructed.
+
+```cpp
+struct list_entry_t {
+ idx_t offset;
+ idx_t length;
+};
+```
+
+The offset refers to the start row in the child Vector, the length keeps track of the size of the list of this row.
+
+List vectors can be stored recursively. For nested list vectors, the child of a list vector is again a list vector.
+
+For example, consider this mock representation of a Vector of type `BIGINT[][]`:
+
+```json
+{
+ "type": "list",
+ "data": "list_entry_t",
+ "child": {
+ "type": "list",
+ "data": "list_entry_t",
+ "child": {
+ "type": "bigint",
+ "data": "int64_t"
+ }
+ }
+}
+```
+
+### Struct Vectors
+
+Struct vectors store a list of child vectors. The number and types of the child vectors is defined by the schema of the struct.
+
+### Map Vectors
+
+Internally map vectors are stored as a `LIST[STRUCT(key KEY_TYPE, value VALUE_TYPE)]`.
+
+### Union Vectors
+
+Internally `UNION` utilizes the same structure as a `STRUCT`.
+The first “child” is always occupied by the Tag Vector of the `UNION`, which records for each row which of the `UNION`'s types apply to that row.
\ No newline at end of file
diff --git a/docs/archive/1.0/operations_manual/footprint_of_duckdb/files_created_by_duckdb.md b/docs/archive/1.0/operations_manual/footprint_of_duckdb/files_created_by_duckdb.md
new file mode 100644
index 00000000000..883c11fc75c
--- /dev/null
+++ b/docs/archive/1.0/operations_manual/footprint_of_duckdb/files_created_by_duckdb.md
@@ -0,0 +1,31 @@
+---
+layout: docu
+title: Files Created by DuckDB
+---
+
+DuckDB creates several files and directories on disk. This page lists both the global and the local ones.
+
+## Global Files and Directories
+
+DuckDB creates the following global files and directories in the user's home directory (denoted with `~`):
+
+| Location | Description | Shared between versions | Shared between clients |
+|-------|-------------------|--|--|
+| `~/.duckdbrc` | The content of this file is executed when starting the [DuckDB CLI client]({% link docs/archive/1.0/api/cli/overview.md %}). The commands can be both [dot command]({% link docs/archive/1.0/api/cli/dot_commands.md %}) and SQL statements. The naming of this file follows the `~/.bashrc` and `~/.zshrc` “run commands” files. | Yes | Only used by CLI |
+| `~/.duckdb_history` | History file, similar to `~/.bash_history` and `~/.zsh_history`. Used by the [DuckDB CLI client]({% link docs/archive/1.0/api/cli/overview.md %}). | Yes | Only used by CLI |
+| `~/.duckdb/extensions` | Binaries of installed [extensions]({% link docs/archive/1.0/extensions/overview.md %}). | No | Yes |
+| `~/.duckdb/stored_secrets` | [Persistent secrets]({% link docs/archive/1.0/configuration/secrets_manager.md %}#persistent-secrets) created by the [Secrets manager]({% link docs/archive/1.0/configuration/secrets_manager.md %}). | Yes | Yes |
+
+## Local Files and Directories
+
+DuckDB creates the following files and directories in the working directory (for in-memory connections) or relative to the database file (for persistent connections):
+
+| Name | Description | Example |
+|-------|-------------------|---|
+| `⟨database_filename⟩` | Database file. Only created in on-disk mode. The file can have any extension with typical extensions being `.duckdb`, `.db`, and `.ddb`. | `weather.duckdb` |
+| `.tmp/` | Temporary directory. Only created in in-memory mode. | `.tmp/` |
+| `⟨database_filename⟩.tmp/` | Temporary directory. Only created in on-disk mode. | `weather.tmp/` |
+| `⟨database_filename⟩.wal` | [Write-ahead log](https://en.wikipedia.org/wiki/Write-ahead_logging) file. If DuckDB exits normally, the WAL file is deleted upon exit. If DuckDB crashes, the WAL file is required to recover data. | `weather.wal` |
+
+If you are working in a Git repository and would like to disable tracking these files by Git,
+see the instructions on using [`.gitignore` for DuckDB]({% link docs/archive/1.0/operations_manual/footprint_of_duckdb/gitignore_for_duckdb.md %}).
\ No newline at end of file
diff --git a/docs/archive/1.0/operations_manual/footprint_of_duckdb/gitignore_for_duckdb.md b/docs/archive/1.0/operations_manual/footprint_of_duckdb/gitignore_for_duckdb.md
new file mode 100644
index 00000000000..b0371fb78e6
--- /dev/null
+++ b/docs/archive/1.0/operations_manual/footprint_of_duckdb/gitignore_for_duckdb.md
@@ -0,0 +1,32 @@
+---
+layout: docu
+title: Gitignore for DuckDB
+---
+
+If you work in a Git repository, you may want to configure your [Gitignore](https://git-scm.com/docs/gitignore) to disable tracking [files created by DuckDB]({% link docs/archive/1.0/operations_manual/footprint_of_duckdb/files_created_by_duckdb.md %}).
+These potentially include the DuckDB database, write ahead log, temporary files.
+
+## Sample Gitignore Files
+
+In the following, we present sample Gitignore configuration snippets for DuckDB.
+
+### Ignore Temporary Files but Keep Database
+
+This configuration is useful if you would like to keep the database file in the version control system:
+
+```text
+*.wal
+*.tmp/
+```
+
+### Ignore Database and Temporary Files
+
+If you would like to ignore both the database and the temporary files, extend the Gitignore file to include the database file.
+The exact Gitignore configuration to achieve this depends on the extension you use for your DuckDB databases (`.duckdb`, `.db`, `.ddb`, etc.).
+For example, if your DuckDB files use the `.duckdb` extension, add the following lines to your `.gitignore` file:
+
+```text
+*.duckdb*
+*.wal
+*.tmp/
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/operations_manual/limits.md b/docs/archive/1.0/operations_manual/limits.md
new file mode 100644
index 00000000000..25b66c77cd1
--- /dev/null
+++ b/docs/archive/1.0/operations_manual/limits.md
@@ -0,0 +1,16 @@
+---
+layout: docu
+title: Limits
+---
+
+This page contains DuckDB's built-in limit values.
+
+| Limit | Default value | Configuration option |
+|---|---|---|
+| Array size | 100000 | - |
+| BLOB size | 4 GB | - |
+| Expression depth | 1000 | [`max_expression_depth`]({% link docs/archive/1.0/configuration/overview.md %}) |
+| Memory allocation for a vector | 128 GB | - |
+| Memory use | 80% of RAM | [`memory_limit`]({% link docs/archive/1.0/configuration/overview.md %}) |
+| String size | 4 GB | - |
+| Temporary directory size | unlimited | [`max_temp_directory_size`]({% link docs/archive/1.0/configuration/overview.md %}) |
\ No newline at end of file
diff --git a/docs/archive/1.0/operations_manual/non-deterministic_behavior.md b/docs/archive/1.0/operations_manual/non-deterministic_behavior.md
new file mode 100644
index 00000000000..7b2aa00ecf3
--- /dev/null
+++ b/docs/archive/1.0/operations_manual/non-deterministic_behavior.md
@@ -0,0 +1,88 @@
+---
+layout: docu
+title: Non-Deterministic Behavior
+---
+
+Several operators in DuckDB exhibit non-deterministic behavior.
+Most notably, SQL uses set semantics, which allows results to be returned in a different order.
+DuckDB exploits this to improve performance, particularly when performing multi-threaded query execution.
+Other factors, such as using different compilers, operating systems, and hardware architectures, can also cause changes in ordering.
+This page documents the cases where non-determinism is an _expected behavior_.
+If you would like to make your queries determinisic, see the [“Working Around Non-Determinism” section](#working-around-non-determinism).
+
+## Set Semantics
+
+One of the most common sources of non-determinism is the set semantics used by SQL.
+E.g., if you run the following query repeatedly, you may get two different results:
+
+```sql
+SELECT *
+FROM (
+ SELECT 'A' AS x
+ UNION
+ SELECT 'B' AS x
+);
+```
+
+Both results `A`, `B` and `B`, `A` are correct.
+
+## Different Results on Different Platforms: `array_distinct`
+
+The `array_distinct` function may return results [in a different order on different platforms](https://github.com/duckdb/duckdb/issues/13746):
+
+```sql
+SELECT array_distinct(['A', 'A', 'B', NULL, NULL]) AS arr;
+```
+
+For this query, both `[A, B]` and `[B, A]` are valid results.
+
+## Floating-Point Aggregate Operations with Multi-Threading
+
+Floating-point inaccuracies may produce different results when run in a multi-threaded configurations:
+For example, [`stddev` and `corr` may produce non-deterministic results](https://github.com/duckdb/duckdb/issues/13763):
+
+```sql
+CREATE TABLE tbl AS
+ SELECT 'ABCDEFG'[floor(random() * 7 + 1)::INT] AS s, 3.7 AS x, i AS y
+ FROM range(1, 1_000_000) r(i);
+
+SELECT s, stddev(x) AS standard_deviation, corr(x, y) AS correlation FROM tbl
+GROUP BY s
+ORDER BY s;
+```
+
+The expected standard deviations and correlations from this query are 0 for all values of `s`.
+However, when executed on multiple threads, the query may return small numbers (`0 <= z < 10e-16`) due to floating-point inaccuracies.
+
+## Working Around Non-Determinism
+
+For the majority of use cases, non-determinism is not causing any issues.
+However, there are some cases where deterministic results are desirable.
+In these cases, try the following workarounds:
+
+1. Limit the number of threads to prevent non-determinism introduced by multi-threading.
+
+ ```sql
+ SET threads = 1;
+ ```
+
+2. Enforce ordering. For example, you can use the [`ORDER BY ALL` clause]({% link docs/archive/1.0/sql/query_syntax/orderby.md %}#order-by-all):
+
+ ```sql
+ SELECT *
+ FROM (
+ SELECT 'A' AS x
+ UNION
+ SELECT 'B' AS x
+ )
+ ORDER BY ALL;
+ ```
+
+ You can also sort lists using [`list_sort`]({% link docs/archive/1.0/sql/functions/list.md %}#list_sortlist)
+
+ ```sql
+ SELECT list_sort(array_distinct(['A', 'A', 'B', NULL, NULL])) AS i
+ ORDER BY i;
+ ```
+
+ It's also possible to introduce a [deterministic shuffling]({% post_url 2024-08-19-duckdb-tricks-part-1 %}#shuffling-data).
\ No newline at end of file
diff --git a/docs/archive/1.0/operations_manual/overview.md b/docs/archive/1.0/operations_manual/overview.md
new file mode 100644
index 00000000000..1c9477f64b0
--- /dev/null
+++ b/docs/archive/1.0/operations_manual/overview.md
@@ -0,0 +1,10 @@
+---
+layout: docu
+title: Overview
+---
+
+We designed DuckDB to be easy to deploy and operate. We believe that most users do not need to consult the pages of the operations manual.
+However, there are certain setups – e.g., when DuckDB is running in mission-critical infrastructure – where we would like to offer advice on how to configure DuckDB.
+The operations manual contains advice for these cases and also offers convenient configuration snippets such as Gitignore files.
+
+For advice on getting the best performance from DuckDB, see also the [Performance Guide]({% link docs/archive/1.0/guides/performance/overview.md %}).
\ No newline at end of file
diff --git a/docs/archive/1.0/operations_manual/securing_duckdb/overview.md b/docs/archive/1.0/operations_manual/securing_duckdb/overview.md
new file mode 100644
index 00000000000..66d6e922bc3
--- /dev/null
+++ b/docs/archive/1.0/operations_manual/securing_duckdb/overview.md
@@ -0,0 +1,92 @@
+---
+layout: docu
+title: Securing DuckDB
+---
+
+DuckDB is quite powerful, which can be problematic, especially if untrusted SQL queries are run, e.g., from public-facing user inputs.
+This page lists some options to restrict the potential fallout from malicious SQL queries.
+
+The approach to securing DuckDB varies depending on your use case, environment, and potential attack models.
+Therefore, consider the security-related configuration options carefully, especially when working with confidential data sets.
+
+## Reporting Vulnerabilities
+
+If you discover a potential vulnerability, please [report it confidentially via GitHub](https://github.com/duckdb/duckdb/security/advisories/new).
+
+## Disabling File Access
+
+DuckDB can list directories and read arbitrary files via its CSV parser’s [`read_csv` function]({% link docs/archive/1.0/data/csv/overview.md %}) or read text via the [`read_text` function]({% link docs/archive/1.0/sql/functions/char.md %}#read_textsource). For example:
+
+```sql
+SELECT *
+FROM read_csv('/etc/passwd', sep = ':');
+```
+
+This can be disabled either by disabling external access altogether (`enable_external_access`) or disabling individual file systems. For example:
+
+```sql
+SET disabled_filesystems = 'LocalFileSystem';
+```
+
+## Secrets
+
+[Secrets]({% link docs/archive/1.0/configuration/secrets_manager.md %}) are used to manage credentials to log into third party services like AWS or Azure. DuckDB can show a list of secrets using the `duckdb_secrets()` table function. This will redact any sensitive information such as security keys by default. The `allow_unredacted_secrets` option can be set to show all information contained within a security key. It is recommended not to turn on this option if you are running untrusted SQL input.
+
+Queries can access the secrets defined in the Secrets Manager. For example, if there is a secret defined to authenticate with a user, who has write privileges to a given AWS S3 bucket, queries may write to that bucket. This is applicable for both persistent and temporary secrets.
+
+[Persistent secrets]({% link docs/archive/1.0/configuration/secrets_manager.md %}#persistent-secrets) are stored in unencrypted binary format on the disk. These have the same permissions as SSH keys, `600`, i.e., only user who is running the DuckDB (parent) process can read and write them.
+
+## Locking Configurations
+
+Security-related configuration settings generally lock themselves for safety reasons. For example, while we can disable [community extensions]({% link docs/archive/1.0/extensions/community_extensions.md %}) using the `SET allow_community_extensions = false`, we cannot re-enable them again after the fact without restarting the database. Trying to do so will result in an error:
+
+```console
+Invalid Input Error: Cannot upgrade allow_community_extensions setting while database is running
+```
+
+This prevents untrusted SQL input from re-enabling settings that were explicitly disabled for security reasons.
+
+Nevertheless, many configuration settings do not disable themselves, such as the resource constraints. If you allow users to run SQL statements unrestricted on your own hardware, it is recommended that you lock the configuration after your own configuration has finished using the following command:
+
+```sql
+SET lock_configuration = true;
+```
+
+This prevents any configuration settings from being modified from that point onwards.
+
+## Constrain Resource Usage
+
+DuckDB can use quite a lot of CPU, RAM, and disk space. To avoid denial of service attacks, these resources can be limited.
+
+The number of CPU threads that DuckDB can use can be set using, for example:
+
+```sql
+SET threads = 4;
+```
+
+Where 4 is the number of allowed threads.
+
+The maximum amount of memory (RAM) can also be limited, for example:
+
+```sql
+SET memory_limit = '4GB';
+```
+
+The size of the temporary file directory can be limited with:
+
+```sql
+SET max_temp_directory_size = '4GB';
+```
+
+## Extensions
+
+DuckDB has a powerful extension mechanism, which have the same privileges as the user running DuckDB's (parent) process.
+This introduces security considerations. Therefore, we recommend reviewing the configuration options for [securing extensions]({% link docs/archive/1.0/operations_manual/securing_duckdb/securing_extensions.md %}).
+
+## Generic Solutions
+
+Securing DuckDB can also be supported via proven means, for example:
+
+* Scoping user privileges via [`chroot`](https://en.wikipedia.org/wiki/Chroot), relying on the operating system
+* Containerization, e.g., Docker and Podman
+* Running DuckDB in WebAssembly
\ No newline at end of file
diff --git a/docs/archive/1.0/operations_manual/securing_duckdb/securing_extensions.md b/docs/archive/1.0/operations_manual/securing_duckdb/securing_extensions.md
new file mode 100644
index 00000000000..74b2734755b
--- /dev/null
+++ b/docs/archive/1.0/operations_manual/securing_duckdb/securing_extensions.md
@@ -0,0 +1,78 @@
+---
+layout: docu
+title: Securing Extensions
+---
+
+DuckDB has a powerful extension mechanism, which have the same privileges as the user running DuckDB's (parent) process.
+This introduces security considerations. Therefore, we recommend reviewing the configuration options listed on this page and setting them according to your attack models.
+
+## DuckDB Signature Checks
+
+DuckDB extensions are checked on every load using the signature of the binaries.
+There are currently three categories of extensions:
+
+* Signed with a `core` key. Only extensions vetted by the core DuckDB team are signed with these keys.
+* Signed with a `community` key. These are open-source extensions distributed via the [DuckDB Community Extensions repository](https://community-extensions.duckdb.org/).
+* Unsigned.
+
+## Overview of Security Levels for Extensions
+
+DuckDB offers the following security levels for extensions.
+
+| Usable extensions | Description | Configuration |
+|-----|---|---|
+| core | Extensions can only be installed from the `core` repository. | `SET allow_community_extensions = false` |
+| core and community | Extensions can only be installed from the `core` and `community` repositories. | This is the default security level. |
+| any extension incl. unsigned | Any extensions can be installed. | `SET allow_unsigned_extensions = true` |
+
+Security-related configuration settings [lock themselves]({% link docs/archive/1.0/operations_manual/securing_duckdb/overview.md %}#locking-configurations), i.e., it is only possible to restrict capabilities in the current process.
+
+For example, attempting the following configuration changes will result in an error:
+
+```sql
+SET allow_community_extensions = false;
+SET allow_community_extensions = true;
+```
+
+```console
+Invalid Input Error: Cannot upgrade allow_community_extensions setting while database is running
+```
+
+## Community Extensions
+
+DuckDB has a [Community Extensions repository]({% link docs/archive/1.0/extensions/community_extensions.md %}), which allows convenient installation of third-party extensions.
+Community extension repositories like pip or npm are essentially enabling remote code execution by design. This is less dramatic than it sounds. For better or worse, we are quite used to piping random scripts from the web into our shells, and routinely install a staggering amount of transitive dependencies without thinking twice. Some repositories like CRAN enforce a human inspection at some point, but that’s no guarantee for anything either.
+
+We’ve studied several different approaches to community extension repositories and have picked what we think is a sensible approach: we do not attempt to review the submissions, but require that the *source code of extensions is available*. We do take over the complete build, sign and distribution process. Note that this is a step up from pip and npm that allow uploading arbitrary binaries but a step down from reviewing everything manually. We allow users to [report malicious extensions](https://github.com/duckdb/community-extensions/security/advisories/new) and show adoption statistics like GitHub stars and download count. Because we manage the repository, we can remove problematic extensions from distribution quickly.
+
+Despite this, installing and loading DuckDB extensions from the community extension repository will execute code written by third party developers, and therefore *can* be dangerous. A malicious developer could create and register a harmless-looking DuckDB extension that steals your crypto coins. If you’re running a web service that executes untrusted SQL from users with DuckDB, it is probably a good idea to disable community extension installation and loading entirely. This can be done like so:
+
+```sql
+SET allow_community_extensions = false;
+```
+
+## Disabling Autoinstalling and Autoloading Known Extensions
+
+By default, DuckDB automatically installs and loads known extensions.
+
+To disable autoinstalling known extensions, run:
+
+```sql
+SET autoinstall_known_extensions = true;
+```
+
+To disable autoloading known extensions, run:
+
+```sql
+SET autoload_known_extensions = true;
+```
+
+To lock this configuration, use the [`lock_configuration` option]({% link docs/archive/1.0/operations_manual/securing_duckdb/overview.md %}#locking-configurations):
+
+```sql
+SET lock_configuration = true;
+```
+
+## Always Require Signed Extensions
+
+By default, DuckDB requires extensions to be either signed as core extensions (created by the DuckDB developers) or community extensions (created by third-party developers but distributed by the DuckDB developers). The `allow_unsigned_extensions` setting can be enabled on start-up to allow running extensions that are not signed at all. While useful for extension development, enabling this setting will allow DuckDB to load any extensions, which means more care must be taken to ensure malicious extensions are not loaded.
\ No newline at end of file
diff --git a/docs/archive/1.0/search.md b/docs/archive/1.0/search.md
new file mode 100644
index 00000000000..039d11a7cf4
--- /dev/null
+++ b/docs/archive/1.0/search.md
@@ -0,0 +1,19 @@
+---
+layout: docu
+title: Search
+---
+
+
+
+
+
+### Partition and Ordering
+
+Partitioning breaks the relation up into independent, unrelated pieces.
+Partitioning is optional, and if none is specified then the entire relation is treated as a single partition.
+Window functions cannot access values outside of the partition containing the row they are being evaluated at.
+
+Ordering is also optional, but without it the results are not well-defined.
+Each partition is ordered using the same ordering clause.
+
+Here is a table of power generation data, available as a CSV file ([`power-plant-generation-history.csv`](/data/power-plant-generation-history.csv)). To load the data, run:
+
+```sql
+CREATE TABLE "Generation History" AS
+ FROM 'power-plant-generation-history.csv';
+```
+
+After partitioning by plant and ordering by date, it will have this layout:
+
+
+
+| Plant | Date | MWh |
+|:---|:---|---:|
+| Boston | 2019-01-02 | 564337 |
+| Boston | 2019-01-03 | 507405 |
+| Boston | 2019-01-04 | 528523 |
+| Boston | 2019-01-05 | 469538 |
+| Boston | 2019-01-06 | 474163 |
+| Boston | 2019-01-07 | 507213 |
+| Boston | 2019-01-08 | 613040 |
+| Boston | 2019-01-09 | 582588 |
+| Boston | 2019-01-10 | 499506 |
+| Boston | 2019-01-11 | 482014 |
+| Boston | 2019-01-12 | 486134 |
+| Boston | 2019-01-13 | 531518 |
+| Worcester | 2019-01-02 | 118860 |
+| Worcester | 2019-01-03 | 101977 |
+| Worcester | 2019-01-04 | 106054 |
+| Worcester | 2019-01-05 | 92182 |
+| Worcester | 2019-01-06 | 94492 |
+| Worcester | 2019-01-07 | 99932 |
+| Worcester | 2019-01-08 | 118854 |
+| Worcester | 2019-01-09 | 113506 |
+| Worcester | 2019-01-10 | 96644 |
+| Worcester | 2019-01-11 | 93806 |
+| Worcester | 2019-01-12 | 98963 |
+| Worcester | 2019-01-13 | 107170 |
+
+In what follows,
+we shall use this table (or small sections of it) to illustrate various pieces of window function evaluation.
+
+The simplest window function is `row_number()`.
+This function just computes the 1-based row number within the partition using the query:
+
+```sql
+SELECT
+ "Plant",
+ "Date",
+ row_number() OVER (PARTITION BY "Plant" ORDER BY "Date") AS "Row"
+FROM "Generation History"
+ORDER BY 1, 2;
+```
+
+The result will be the following:
+
+
+
+| Plant | Date | Row |
+|:---|:---|---:|
+| Boston | 2019-01-02 | 1 |
+| Boston | 2019-01-03 | 2 |
+| Boston | 2019-01-04 | 3 |
+| ... | ... | ... |
+| Worcester | 2019-01-02 | 1 |
+| Worcester | 2019-01-03 | 2 |
+| Worcester | 2019-01-04 | 3 |
+| ... | ... | ... |
+
+Note that even though the function is computed with an `ORDER BY` clause,
+the result does not have to be sorted,
+so the `SELECT` also needs to be explicitly sorted if that is desired.
+
+### Framing
+
+Framing specifies a set of rows relative to each row where the function is evaluated.
+The distance from the current row is given as an expression either `PRECEDING` or `FOLLOWING` the current row.
+This distance can either be specified as an integral number of `ROWS`
+or as a `RANGE` delta expression from the value of the ordering expression.
+For a `RANGE` specification, there must be only one ordering expression,
+and it has to support addition and subtraction (i.e., numbers or `INTERVAL`s).
+The default values for frames are from `UNBOUNDED PRECEDING` to `CURRENT ROW`.
+It is invalid for a frame to start after it ends.
+Using the [`EXCLUDE` clause](#exclude-clause), rows around the current row can be excluded from the frame.
+
+#### `ROW` Framing
+
+Here is a simple `ROW` frame query, using an aggregate function:
+
+```sql
+SELECT points,
+ sum(points) OVER (
+ ROWS BETWEEN 1 PRECEDING
+ AND 1 FOLLOWING) we
+FROM results;
+```
+
+This query computes the `sum` of each point and the points on either side of it:
+
+
+
+Notice that at the edge of the partition, there are only two values added together.
+This is because frames are cropped to the edge of the partition.
+
+#### `RANGE` Framing
+
+Returning to the power data, suppose the data is noisy.
+We might want to compute a 7 day moving average for each plant to smooth out the noise.
+To do this, we can use this window query:
+
+```sql
+SELECT "Plant", "Date",
+ avg("MWh") OVER (
+ PARTITION BY "Plant"
+ ORDER BY "Date" ASC
+ RANGE BETWEEN INTERVAL 3 DAYS PRECEDING
+ AND INTERVAL 3 DAYS FOLLOWING)
+ AS "MWh 7-day Moving Average"
+FROM "Generation History"
+ORDER BY 1, 2;
+```
+
+This query partitions the data by `Plant` (to keep the different power plants' data separate),
+orders each plant's partition by `Date` (to put the energy measurements next to each other),
+and uses a `RANGE` frame of three days on either side of each day for the `avg`
+(to handle any missing days).
+This is the result:
+
+
+
+| Plant | Date | MWh 7-day Moving Average |
+|:---|:---|---:|
+| Boston | 2019-01-02 | 517450.75 |
+| Boston | 2019-01-03 | 508793.20 |
+| Boston | 2019-01-04 | 508529.83 |
+| ... | ... | ... |
+| Boston | 2019-01-13 | 499793.00 |
+| Worcester | 2019-01-02 | 104768.25 |
+| Worcester | 2019-01-03 | 102713.00 |
+| Worcester | 2019-01-04 | 102249.50 |
+| ... | ... | ... |
+
+#### `EXCLUDE` Clause
+
+The `EXCLUDE` clause allows rows around the current row to be excluded from the frame. It has the following options:
+
+* `EXCLUDE NO OTHERS`: exclude nothing (default)
+* `EXCLUDE CURRENT ROW`: exclude the current row from the window frame
+* `EXCLUDE GROUP`: exclude the current row and all its peers (according to the columns specified by `ORDER BY`) from the window frame
+* `EXCLUDE TIES`: exclude only the current row's peers from the window frame
+
+### `WINDOW` Clauses
+
+Multiple different `OVER` clauses can be specified in the same `SELECT`, and each will be computed separately.
+Often, however, we want to use the same layout for multiple window functions.
+The `WINDOW` clause can be used to define a *named* window that can be shared between multiple window functions:
+
+```sql
+SELECT "Plant", "Date",
+ min("MWh") OVER seven AS "MWh 7-day Moving Minimum",
+ avg("MWh") OVER seven AS "MWh 7-day Moving Average",
+ max("MWh") OVER seven AS "MWh 7-day Moving Maximum"
+FROM "Generation History"
+WINDOW seven AS (
+ PARTITION BY "Plant"
+ ORDER BY "Date" ASC
+ RANGE BETWEEN INTERVAL 3 DAYS PRECEDING
+ AND INTERVAL 3 DAYS FOLLOWING)
+ORDER BY 1, 2;
+```
+
+The three window functions will also share the data layout, which will improve performance.
+
+Multiple windows can be defined in the same `WINDOW` clause by comma-separating them:
+
+```sql
+SELECT "Plant", "Date",
+ min("MWh") OVER seven AS "MWh 7-day Moving Minimum",
+ avg("MWh") OVER seven AS "MWh 7-day Moving Average",
+ max("MWh") OVER seven AS "MWh 7-day Moving Maximum",
+ min("MWh") OVER three AS "MWh 3-day Moving Minimum",
+ avg("MWh") OVER three AS "MWh 3-day Moving Average",
+ max("MWh") OVER three AS "MWh 3-day Moving Maximum"
+FROM "Generation History"
+WINDOW
+ seven AS (
+ PARTITION BY "Plant"
+ ORDER BY "Date" ASC
+ RANGE BETWEEN INTERVAL 3 DAYS PRECEDING
+ AND INTERVAL 3 DAYS FOLLOWING),
+ three AS (
+ PARTITION BY "Plant"
+ ORDER BY "Date" ASC
+ RANGE BETWEEN INTERVAL 1 DAYS PRECEDING
+ AND INTERVAL 1 DAYS FOLLOWING)
+ORDER BY 1, 2;
+```
+
+The queries above do not use a number of clauses commonly found in select statements, like
+`WHERE`, `GROUP BY`, etc. For more complex queries you can find where `WINDOW` clauses fall in
+the canonical order of the [`SELECT statement`]({% link docs/archive/1.0/sql/statements/select.md %}).
+
+### Filtering the Results of Window Functions Using `QUALIFY`
+
+Window functions are executed after the [`WHERE`]({% link docs/archive/1.0/sql/query_syntax/where.md %}) and [`HAVING`]({% link docs/archive/1.0/sql/query_syntax/having.md %}) clauses have been already evaluated, so it's not possible to use these clauses to filter the results of window functions
+The [`QUALIFY` clause]({% link docs/archive/1.0/sql/query_syntax/qualify.md %}) avoids the need for a subquery or [`WITH` clause]({% link docs/archive/1.0/sql/query_syntax/with.md %}) to perform this filtering.
+
+### Box and Whisker Queries
+
+All aggregates can be used as windowing functions, including the complex statistical functions.
+These function implementations have been optimised for windowing,
+and we can use the window syntax to write queries that generate the data for moving box-and-whisker plots:
+
+```sql
+SELECT "Plant", "Date",
+ min("MWh") OVER seven AS "MWh 7-day Moving Minimum",
+ quantile_cont("MWh", [0.25, 0.5, 0.75]) OVER seven
+ AS "MWh 7-day Moving IQR",
+ max("MWh") OVER seven AS "MWh 7-day Moving Maximum",
+FROM "Generation History"
+WINDOW seven AS (
+ PARTITION BY "Plant"
+ ORDER BY "Date" ASC
+ RANGE BETWEEN INTERVAL 3 DAYS PRECEDING
+ AND INTERVAL 3 DAYS FOLLOWING)
+ORDER BY 1, 2;
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/indexes.md b/docs/archive/1.0/sql/indexes.md
new file mode 100644
index 00000000000..063285d9c71
--- /dev/null
+++ b/docs/archive/1.0/sql/indexes.md
@@ -0,0 +1,70 @@
+---
+layout: docu
+railroad: statements/indexes.js
+title: Indexes
+---
+
+## Index Types
+
+DuckDB currently uses two index types:
+
+* A [min-max index](https://en.wikipedia.org/wiki/Block_Range_Index) (also known as zonemap and block range index) is automatically created for columns of all [general-purpose data types]({% link docs/archive/1.0/sql/data_types/overview.md %}).
+* An [Adaptive Radix Tree (ART)](https://db.in.tum.de/~leis/papers/ART.pdf) is mainly used to ensure primary key constraints and to speed up point and very highly selective (i.e., < 0.1%) queries. Such an index is automatically created for columns with a `UNIQUE` or `PRIMARY KEY` constraint and can be defined using `CREATE INDEX`.
+
+> Warning ART indexes must currently be able to fit in-memory. Avoid creating ART indexes if the index does not fit in memory.
+
+## Persistence
+
+Both min-max indexes and ART indexes are persisted on disk.
+
+## `CREATE INDEX` and `DROP INDEX`
+
+To create an index, use the [`CREATE INDEX` statement]({% link docs/archive/1.0/sql/statements/create_index.md %}#create-index).
+To drop an index, use the [`DROP INDEX` statement]({% link docs/archive/1.0/sql/statements/create_index.md %}#drop-index).
+
+## Limitations of ART Indexes
+
+ART indexes create a secondary copy of the data in a second location – this complicates processing, particularly when combined with transactions. Certain limitations apply when it comes to modifying data that is also stored in secondary indexes.
+
+> As expected, indexes have a strong effect on performance, slowing down loading and updates, but speeding up certain queries. Please consult the [Performance Guide]({% link docs/archive/1.0/guides/performance/indexing.md %}) for details.
+
+### Updates Become Deletes and Inserts
+
+When an update statement is executed on a column that is present in an index, the statement is transformed into a *delete* of the original row followed by an *insert*.
+This has certain performance implications, particularly for wide tables, as entire rows are rewritten instead of only the affected columns.
+
+### Over-Eager Unique Constraint Checking
+
+Due to the presence of transactions, data can only be removed from the index after (1) the transaction that performed the delete is committed, and (2) no further transactions exist that refer to the old entry still present in the index. As a result of this – transactions that perform *deletions followed by insertions* may trigger unexpected unique constraint violations, as the deleted tuple has not actually been removed from the index yet. For example:
+
+```sql
+CREATE TABLE students (id INTEGER, name VARCHAR);
+INSERT INTO students VALUES (1, 'John Doe');
+CREATE UNIQUE INDEX students_id ON students (id);
+
+BEGIN; -- start transaction
+DELETE FROM students WHERE id = 1;
+INSERT INTO students VALUES (1, 'Jane Doe');
+```
+
+The last statement fails with the following error:
+
+```console
+Constraint Error: Duplicate key "id: 1" violates unique constraint. If this is an unexpected constraint violation please double check with the known index limitations section in our documentation (https://duckdb.org/docs/sql/indexes).
+```
+
+This, combined with the fact that updates are turned into deletions and insertions within the same transaction, means that updating rows in the presence of unique or primary key constraints can often lead to unexpected unique constraint violations. For example, in the following query, `SET id = 1` causes a `Constraint Error` to occur.
+
+```sql
+CREATE TABLE students (id INTEGER PRIMARY KEY, name VARCHAR);
+INSERT INTO students VALUES (1, 'John Doe');
+
+UPDATE students SET id = 1 WHERE id = 1;
+```
+
+```console
+Constraint Error: Duplicate key "id: 1" violates primary key constraint.
+If this is an unexpected constraint violation please double check with the known index limitations section in our documentation (https://duckdb.org/docs/sql/indexes).
+```
+
+Currently, this is an expected limitation of DuckDB – although we aim to resolve this in the future.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/introduction.md b/docs/archive/1.0/sql/introduction.md
new file mode 100644
index 00000000000..e5ea14ace7e
--- /dev/null
+++ b/docs/archive/1.0/sql/introduction.md
@@ -0,0 +1,403 @@
+---
+layout: docu
+title: SQL Introduction
+---
+
+Here we provide an overview of how to perform simple operations in SQL.
+This tutorial is only intended to give you an introduction and is in no way a complete tutorial on SQL.
+This tutorial is adapted from the [PostgreSQL tutorial](https://www.postgresql.org/docs/11/tutorial-sql-intro.html).
+
+> DuckDB's SQL dialect closely follows the conventions of the PostgreSQL dialect.
+> The few exceptions to this are listed on the [PostgreSQL compatibility page]({% link docs/archive/1.0/sql/dialect/postgresql_compatibility.md %}).
+
+In the examples that follow, we assume that you have installed the DuckDB Command Line Interface (CLI) shell. See the [installation page]({% link docs/archive/1.0/installation/index.html %}?environment=cli) for information on how to install the CLI.
+
+## Concepts
+
+DuckDB is a relational database management system (RDBMS). That means it is a system for managing data stored in relations. A relation is essentially a mathematical term for a table.
+
+Each table is a named collection of rows. Each row of a given table has the same set of named columns, and each column is of a specific data type. Tables themselves are stored inside schemas, and a collection of schemas constitutes the entire database that you can access.
+
+## Creating a New Table
+
+You can create a new table by specifying the table name, along with all column names and their types:
+
+```sql
+CREATE TABLE weather (
+ city VARCHAR,
+ temp_lo INTEGER, -- minimum temperature on a day
+ temp_hi INTEGER, -- maximum temperature on a day
+ prcp FLOAT,
+ date DATE
+);
+```
+
+You can enter this into the shell with the line breaks. The command is not terminated until the semicolon.
+
+White space (i.e., spaces, tabs, and newlines) can be used freely in SQL commands. That means you can type the command aligned differently than above, or even all on one line. Two dash characters (`--`) introduce comments. Whatever follows them is ignored up to the end of the line. SQL is case-insensitive about keywords and identifiers. When returning identifiers, [their original cases are preserved]({% link docs/archive/1.0/sql/dialect/keywords_and_identifiers.md %}#rules-for-case-sensitivity).
+
+In the SQL command, we first specify the type of command that we want to perform: `CREATE TABLE`. After that follows the parameters for the command. First, the table name, `weather`, is given. Then the column names and column types follow.
+
+`city VARCHAR` specifies that the table has a column called `city` that is of type `VARCHAR`. `VARCHAR` specifies a data type that can store text of arbitrary length. The temperature fields are stored in an `INTEGER` type, a type that stores integer numbers (i.e., whole numbers without a decimal point). `FLOAT` columns store single precision floating-point numbers (i.e., numbers with a decimal point). `DATE` stores a date (i.e., year, month, day combination). `DATE` only stores the specific day, not a time associated with that day.
+
+DuckDB supports the standard SQL types `INTEGER`, `SMALLINT`, `FLOAT`, `DOUBLE`, `DECIMAL`, `CHAR(n)`, `VARCHAR(n)`, `DATE`, `TIME` and `TIMESTAMP`.
+
+The second example will store cities and their associated geographical location:
+
+```sql
+CREATE TABLE cities (
+ name VARCHAR,
+ lat DECIMAL,
+ lon DECIMAL
+);
+```
+
+Finally, it should be mentioned that if you don't need a table any longer or want to recreate it differently you can remove it using the following command:
+
+```sql
+DROP TABLE ⟨tablename⟩;
+```
+
+## Populating a Table with Rows
+
+The insert statement is used to populate a table with rows:
+
+```sql
+INSERT INTO weather
+VALUES ('San Francisco', 46, 50, 0.25, '1994-11-27');
+```
+
+Constants that are not numeric values (e.g., text and dates) must be surrounded by single quotes (`''`), as in the example. Input dates for the date type must be formatted as `'YYYY-MM-DD'`.
+
+We can insert into the `cities` table in the same manner.
+
+```sql
+INSERT INTO cities
+VALUES ('San Francisco', -194.0, 53.0);
+```
+
+The syntax used so far requires you to remember the order of the columns. An alternative syntax allows you to list the columns explicitly:
+
+```sql
+INSERT INTO weather (city, temp_lo, temp_hi, prcp, date)
+VALUES ('San Francisco', 43, 57, 0.0, '1994-11-29');
+```
+
+You can list the columns in a different order if you wish or even omit some columns, e.g., if the `prcp` is unknown:
+
+```sql
+INSERT INTO weather (date, city, temp_hi, temp_lo)
+VALUES ('1994-11-29', 'Hayward', 54, 37);
+```
+
+> Tip Many developers consider explicitly listing the columns better style than relying on the order implicitly.
+
+Please enter all the commands shown above so you have some data to work with in the following sections.
+
+Alternatively, you can use the `COPY` statement. This is faster for large amounts of data because the `COPY` command is optimized for bulk loading while allowing less flexibility than `INSERT`. An example with [`weather.csv`](/data/weather.csv) would be:
+
+```sql
+COPY weather
+FROM 'weather.csv';
+```
+
+Where the file name for the source file must be available on the machine running the process. There are many other ways of loading data into DuckDB, see the [corresponding documentation section]({% link docs/archive/1.0/data/overview.md %}) for more information.
+
+## Querying a Table
+
+To retrieve data from a table, the table is queried. A SQL `SELECT` statement is used to do this. The statement is divided into a select list (the part that lists the columns to be returned), a table list (the part that lists the tables from which to retrieve the data), and an optional qualification (the part that specifies any restrictions). For example, to retrieve all the rows of table weather, type:
+
+```sql
+SELECT *
+FROM weather;
+```
+
+Here `*` is a shorthand for “all columns”. So the same result would be had with:
+
+```sql
+SELECT city, temp_lo, temp_hi, prcp, date
+FROM weather;
+```
+
+The output should be:
+
+| city | temp_lo | temp_hi | prcp | date |
+|---------------|---------|---------|------|------------|
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 |
+| San Francisco | 43 | 57 | 0.0 | 1994-11-29 |
+| Hayward | 37 | 54 | NULL | 1994-11-29 |
+
+You can write expressions, not just simple column references, in the select list. For example, you can do:
+
+```sql
+SELECT city, (temp_hi + temp_lo) / 2 AS temp_avg, date
+FROM weather;
+```
+
+This should give:
+
+| city | temp_avg | date |
+|---------------|----------|------------|
+| San Francisco | 48.0 | 1994-11-27 |
+| San Francisco | 50.0 | 1994-11-29 |
+| Hayward | 45.5 | 1994-11-29 |
+
+Notice how the `AS` clause is used to relabel the output column. (The `AS` clause is optional.)
+
+A query can be “qualified” by adding a `WHERE` clause that specifies which rows are wanted. The `WHERE` clause contains a Boolean (truth value) expression, and only rows for which the Boolean expression is true are returned. The usual Boolean operators (`AND`, `OR`, and `NOT`) are allowed in the qualification. For example, the following retrieves the weather of San Francisco on rainy days:
+
+```sql
+SELECT *
+FROM weather
+WHERE city = 'San Francisco'
+ AND prcp > 0.0;
+```
+
+Result:
+
+| city | temp_lo | temp_hi | prcp | date |
+|---------------|---------|---------|------|------------|
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 |
+
+You can request that the results of a query be returned in sorted order:
+
+```sql
+SELECT *
+FROM weather
+ORDER BY city;
+```
+
+| city | temp_lo | temp_hi | prcp | date |
+|---------------|---------|---------|------|------------|
+| Hayward | 37 | 54 | NULL | 1994-11-29 |
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 |
+| San Francisco | 43 | 57 | 0.0 | 1994-11-29 |
+
+In this example, the sort order isn't fully specified, and so you might get the San Francisco rows in either order. But you'd always get the results shown above if you do:
+
+```sql
+SELECT *
+FROM weather
+ORDER BY city, temp_lo;
+```
+
+You can request that duplicate rows be removed from the result of a query:
+
+```sql
+SELECT DISTINCT city
+FROM weather;
+```
+
+| city |
+|---------------|
+| San Francisco |
+| Hayward |
+
+Here again, the result row ordering might vary. You can ensure consistent results by using `DISTINCT` and `ORDER BY` together:
+
+```sql
+SELECT DISTINCT city
+FROM weather
+ORDER BY city;
+```
+
+## Joins between Tables
+
+Thus far, our queries have only accessed one table at a time. Queries can access multiple tables at once, or access the same table in such a way that multiple rows of the table are being processed at the same time. A query that accesses multiple rows of the same or different tables at one time is called a join query. As an example, say you wish to list all the weather records together with the location of the associated city. To do that, we need to compare the city column of each row of the `weather` table with the name column of all rows in the `cities` table, and select the pairs of rows where these values match.
+
+This would be accomplished by the following query:
+
+```sql
+SELECT *
+FROM weather, cities
+WHERE city = name;
+```
+
+| city | temp_lo | temp_hi | prcp | date | name | lat | lon |
+|---------------|---------|---------|------|------------|---------------|----------|--------|
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 | San Francisco | -194.000 | 53.000 |
+| San Francisco | 43 | 57 | 0.0 | 1994-11-29 | San Francisco | -194.000 | 53.000 |
+
+Observe two things about the result set:
+
+* There is no result row for the city of Hayward. This is because there is no matching entry in the `cities` table for Hayward, so the join ignores the unmatched rows in the `weather` table. We will see shortly how this can be fixed.
+* There are two columns containing the city name. This is correct because the lists of columns from the `weather` and `cities` tables are concatenated. In practice this is undesirable, though, so you will probably want to list the output columns explicitly rather than using `*`:
+
+```sql
+SELECT city, temp_lo, temp_hi, prcp, date, lon, lat
+FROM weather, cities
+WHERE city = name;
+```
+
+| city | temp_lo | temp_hi | prcp | date | lon | lat |
+|---------------|---------|---------|------|------------|--------|----------|
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 | 53.000 | -194.000 |
+| San Francisco | 43 | 57 | 0.0 | 1994-11-29 | 53.000 | -194.000 |
+
+Since the columns all had different names, the parser automatically found which table they belong to. If there were duplicate column names in the two tables you'd need to qualify the column names to show which one you meant, as in:
+
+```sql
+SELECT weather.city, weather.temp_lo, weather.temp_hi,
+ weather.prcp, weather.date, cities.lon, cities.lat
+FROM weather, cities
+WHERE cities.name = weather.city;
+```
+
+It is widely considered good style to qualify all column names in a join query, so that the query won't fail if a duplicate column name is later added to one of the tables.
+
+Join queries of the kind seen thus far can also be written in this alternative form:
+
+```sql
+SELECT *
+FROM weather
+INNER JOIN cities ON weather.city = cities.name;
+```
+
+This syntax is not as commonly used as the one above, but we show it here to help you understand the following topics.
+
+Now we will figure out how we can get the Hayward records back in. What we want the query to do is to scan the `weather` table and for each row to find the matching cities row(s). If no matching row is found we want some “empty values” to be substituted for the `cities` table's columns. This kind of query is called an outer join. (The joins we have seen so far are inner joins.) The command looks like this:
+
+```sql
+SELECT *
+FROM weather
+LEFT OUTER JOIN cities ON weather.city = cities.name;
+```
+
+| city | temp_lo | temp_hi | prcp | date | name | lat | lon |
+|---------------|---------|---------|------|------------|---------------|----------|--------|
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 | San Francisco | -194.000 | 53.000 |
+| San Francisco | 43 | 57 | 0.0 | 1994-11-29 | San Francisco | -194.000 | 53.000 |
+| Hayward | 37 | 54 | NULL | 1994-11-29 | NULL | NULL | NULL |
+
+This query is called a left outer join because the table mentioned on the left of the join operator will have each of its rows in the output at least once, whereas the table on the right will only have those rows output that match some row of the left table. When outputting a left-table row for which there is no right-table match, empty (null) values are substituted for the right-table columns.
+
+## Aggregate Functions
+
+Like most other relational database products, DuckDB supports aggregate functions. An aggregate function computes a single result from multiple input rows. For example, there are aggregates to compute the `count`, `sum`, `avg` (average), `max` (maximum) and `min` (minimum) over a set of rows.
+
+As an example, we can find the highest low-temperature reading anywhere with:
+
+```sql
+SELECT max(temp_lo)
+FROM weather;
+```
+
+| max(temp_lo) |
+|--------------|
+| 46 |
+
+If we wanted to know what city (or cities) that reading occurred in, we might try:
+
+```sql
+SELECT city
+FROM weather
+WHERE temp_lo = max(temp_lo); -- WRONG
+```
+
+but this will not work since the aggregate max cannot be used in the `WHERE` clause. (This restriction exists because the `WHERE` clause determines which rows will be included in the aggregate calculation; so obviously it has to be evaluated before aggregate functions are computed.) However, as is often the case the query can be restated to accomplish the desired result, here by using a subquery:
+
+```sql
+SELECT city
+FROM weather
+WHERE temp_lo = (SELECT max(temp_lo) FROM weather);
+```
+
+| city |
+|---------------|
+| San Francisco |
+
+This is OK because the subquery is an independent computation that computes its own aggregate separately from what is happening in the outer query.
+
+Aggregates are also very useful in combination with `GROUP BY` clauses. For example, we can get the maximum low temperature observed in each city with:
+
+```sql
+SELECT city, max(temp_lo)
+FROM weather
+GROUP BY city;
+```
+
+| city | max(temp_lo) |
+|---------------|--------------|
+| San Francisco | 46 |
+| Hayward | 37 |
+
+Which gives us one output row per city. Each aggregate result is computed over the table rows matching that city. We can filter these grouped rows using `HAVING`:
+
+```sql
+SELECT city, max(temp_lo)
+FROM weather
+GROUP BY city
+HAVING max(temp_lo) < 40;
+```
+
+| city | max(temp_lo) |
+|---------|--------------|
+| Hayward | 37 |
+
+which gives us the same results for only the cities that have all `temp_lo` values below 40. Finally, if we only care about cities whose names begin with `S`, we can use the `LIKE` operator:
+
+```sql
+SELECT city, max(temp_lo)
+FROM weather
+WHERE city LIKE 'S%' -- (1)
+GROUP BY city
+HAVING max(temp_lo) < 40;
+```
+
+More information about the `LIKE` operator can be found in the [pattern matching page]({% link docs/archive/1.0/sql/functions/pattern_matching.md %}).
+
+It is important to understand the interaction between aggregates and SQL's `WHERE` and `HAVING` clauses. The fundamental difference between `WHERE` and `HAVING` is this: `WHERE` selects input rows before groups and aggregates are computed (thus, it controls which rows go into the aggregate computation), whereas `HAVING` selects group rows after groups and aggregates are computed. Thus, the `WHERE` clause must not contain aggregate functions; it makes no sense to try to use an aggregate to determine which rows will be inputs to the aggregates. On the other hand, the `HAVING` clause always contains aggregate functions.
+
+In the previous example, we can apply the city name restriction in `WHERE`, since it needs no aggregate. This is more efficient than adding the restriction to `HAVING`, because we avoid doing the grouping and aggregate calculations for all rows that fail the `WHERE` check.
+
+## Updates
+
+You can update existing rows using the `UPDATE` command. Suppose you discover the temperature readings are all off by 2 degrees after November 28. You can correct the data as follows:
+
+```sql
+UPDATE weather
+SET temp_hi = temp_hi - 2, temp_lo = temp_lo - 2
+WHERE date > '1994-11-28';
+```
+
+Look at the new state of the data:
+
+```sql
+SELECT *
+FROM weather;
+```
+
+| city | temp_lo | temp_hi | prcp | date |
+|---------------|---------|---------|------|------------|
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 |
+| San Francisco | 43 | 57 | 0.0 | 1994-11-29 |
+| Hayward | 37 | 54 | NULL | 1994-11-29 |
+
+## Deletions
+
+Rows can be removed from a table using the `DELETE` command. Suppose you are no longer interested in the weather of Hayward. Then you can do the following to delete those rows from the table:
+
+```sql
+DELETE FROM weather
+WHERE city = 'Hayward';
+```
+
+All weather records belonging to Hayward are removed.
+
+```sql
+SELECT *
+FROM weather;
+```
+
+| city | temp_lo | temp_hi | prcp | date |
+|---------------|---------|---------|------|------------|
+| San Francisco | 46 | 50 | 0.25 | 1994-11-27 |
+| San Francisco | 43 | 57 | 0.0 | 1994-11-29 |
+
+One should be cautious when issuing statements of the following form:
+
+```sql
+DELETE FROM ⟨table_name⟩;
+```
+
+> Warning Without a qualification, `DELETE` will remove all rows from the given table, leaving it empty. The system will not request confirmation before doing this.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/meta/duckdb_table_functions.md b/docs/archive/1.0/sql/meta/duckdb_table_functions.md
new file mode 100644
index 00000000000..2711db23337
--- /dev/null
+++ b/docs/archive/1.0/sql/meta/duckdb_table_functions.md
@@ -0,0 +1,340 @@
+---
+layout: docu
+redirect_from:
+- docs/archive/1.0/sql/duckdb_table_functions
+title: DuckDB_% Metadata Functions
+---
+
+DuckDB offers a collection of table functions that provide metadata about the current database. These functions reside in the `main` schema and their names are prefixed with `duckdb_`.
+
+The resultset returned by a `duckdb_` table function may be used just like an ordinary table or view. For example, you can use a `duckdb_` function call in the `FROM` clause of a `SELECT` statement, and you may refer to the columns of its returned resultset elsewhere in the statement, for example in the `WHERE` clause.
+
+Table functions are still functions, and you should write parenthesis after the function name to call it to obtain its returned resultset:
+
+```sql
+SELECT * FROM duckdb_settings();
+```
+
+Alternatively, you may execute table functions also using the `CALL`-syntax:
+
+```sql
+CALL duckdb_settings();
+```
+
+In this case too, the parentheses are mandatory.
+
+> For some of the `duckdb_%` functions, there is also an identically named view available, which also resides in the `main` schema. Typically, these views do a `SELECT` on the `duckdb_` table function with the same name, while filtering out those objects that are marked as internal. We mention it here, because if you accidentally omit the parentheses in your `duckdb_` table function call, you might still get a result, but from the identically named view.
+
+Example:
+
+The `duckdb_views()` _table function_ returns all views, including those marked internal:
+
+```sql
+SELECT * FROM duckdb_views();
+```
+
+The `duckdb_views` _view_ returns views that are not marked as internal:
+
+```sql
+SELECT * FROM duckdb_views;
+```
+
+## `duckdb_columns`
+
+The `duckdb_columns()` function provides metadata about the columns available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains the column object. | `VARCHAR` |
+| `database_oid` | Internal identifier of the database that contains the column object. | `BIGINT` |
+| `schema_name` | The SQL name of the schema that contains the table object that defines this column. | `VARCHAR` |
+| `schema_oid` | Internal identifier of the schema object that contains the table of the column. | `BIGINT` |
+| `table_name` | The SQL name of the table that defines the column. | `VARCHAR` |
+| `table_oid` | Internal identifier (name) of the table object that defines the column. | `BIGINT` |
+| `column_name` | The SQL name of the column. | `VARCHAR` |
+| `column_index` | The unique position of the column within its table. | `INTEGER` |
+| `internal` | `true` if this column built-in, `false` if it is user-defined. | `BOOLEAN` |
+| `column_default` | The default value of the column (expressed in SQL)| `VARCHAR` |
+| `is_nullable` | `true` if the column can hold `NULL` values; `false` if the column cannot hold `NULL`-values. | `BOOLEAN` |
+| `data_type` | The name of the column datatype. | `VARCHAR` |
+| `data_type_id` | The internal identifier of the column data type. | `BIGINT` |
+| `character_maximum_length` | Always `NULL`. DuckDB [text types]({% link docs/archive/1.0/sql/data_types/text.md %}) do not enforce a value length restriction based on a length type parameter. | `INTEGER` |
+| `numeric_precision` | The number of units (in the base indicated by `numeric_precision_radix`) used for storing column values. For integral and approximate numeric types, this is the number of bits. For decimal types, this is the number of digits positions. | `INTEGER` |
+| `numeric_precision_radix` | The number-base of the units in the `numeric_precision` column. For integral and approximate numeric types, this is `2`, indicating the precision is expressed as a number of bits. For the `decimal` type this is `10`, indicating the precision is expressed as a number of decimal positions. | `INTEGER` |
+| `numeric_scale` | Applicable to `decimal` type. Indicates the maximum number of fractional digits (i.e., the number of digits that may appear after the decimal separator). | `INTEGER` |
+
+The [`information_schema.columns`]({% link docs/archive/1.0/sql/meta/information_schema.md %}#columns-columns) system view provides a more standardized way to obtain metadata about database columns, but the `duckdb_columns` function also returns metadata about DuckDB internal objects. (In fact, `information_schema.columns` is implemented as a query on top of `duckdb_columns()`)
+
+## `duckdb_constraints`
+
+The `duckdb_constraints()` function provides metadata about the constraints available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains the constraint. | `VARCHAR` |
+| `database_oid` | Internal identifier of the database that contains the constraint. | `BIGINT` |
+| `schema_name` | The SQL name of the schema that contains the table on which the constraint is defined. | `VARCHAR` |
+| `schema_oid` | Internal identifier of the schema object that contains the table on which the constraint is defined. | `BIGINT` |
+| `table_name` | The SQL name of the table on which the constraint is defined. | `VARCHAR` |
+| `table_oid` | Internal identifier (name) of the table object on which the constraint is defined. | `BIGINT` |
+| `constraint_index` | Indicates the position of the constraint as it appears in its table definition. | `BIGINT` |
+| `constraint_type` | Indicates the type of constraint. Applicable values are `CHECK`, `FOREIGN KEY`, `PRIMARY KEY`, `NOT NULL`, `UNIQUE`. | `VARCHAR` |
+| `constraint_text` | The definition of the constraint expressed as a SQL-phrase. (Not necessarily a complete or syntactically valid DDL-statement.)| `VARCHAR` |
+| `expression` | If constraint is a check constraint, the definition of the condition being checked, otherwise `NULL`. | `VARCHAR` |
+| `constraint_column_indexes` | An array of table column indexes referring to the columns that appear in the constraint definition. | `BIGINT[]` |
+| `constraint_column_names` | An array of table column names appearing in the constraint definition. | `VARCHAR[]` |
+
+The [`information_schema.referential_constraints`]({% link docs/archive/1.0/sql/meta/information_schema.md %}#referential_constraints-referential-constraints) and [`information_schema.table_constraints`]({% link docs/archive/1.0/sql/meta/information_schema.md %}#table_constraints-table-constraints) system views provide a more standardized way to obtain metadata about constraints, but the `duckdb_constraints` function also returns metadata about DuckDB internal objects. (In fact, `information_schema.referential_constraints` and `information_schema.table_constraints` are implemented as a query on top of `duckdb_constraints()`)
+
+## `duckdb_databases`
+
+The `duckdb_databases()` function lists the databases that are accessible from within the current DuckDB process.
+Apart from the database associated at startup, the list also includes databases that were [attached]({% link docs/archive/1.0/sql/statements/attach.md %}) later on to the DuckDB process
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database, or the alias if the database was attached using an ALIAS-clause. | `VARCHAR` |
+| `database_oid` | The internal identifier of the database. | `VARCHAR` |
+| `path` | The file path associated with the database. | `VARCHAR` |
+| `internal` | `true` indicates a system or built-in database. False indicates a user-defined database. | `BOOLEAN` |
+| `type` | The type indicates the type of RDBMS implemented by the attached database. For DuckDB databases, that value is `duckdb`. | `VARCHAR` |
+
+## `duckdb_dependencies`
+
+The `duckdb_dependencies()` function provides metadata about the dependencies available in the DuckDB instance.
+
+| Column | Description | Type |
+|:--|:------|:-|
+| `classid` | Always 0| `BIGINT` |
+| `objid` | The internal id of the object. | `BIGINT` |
+| `objsubid` | Always 0| `INTEGER` |
+| `refclassid` | Always 0| `BIGINT` |
+| `refobjid` | The internal id of the dependent object. | `BIGINT` |
+| `refobjsubid` | Always 0| `INTEGER` |
+| `deptype` | The type of dependency. Either regular (n) or automatic (a). | `VARCHAR` |
+
+## `duckdb_extensions`
+
+The `duckdb_extensions()` function provides metadata about the extensions available in the DuckDB instance.
+
+| Column | Description | Type |
+|:--|:------|:-|
+| `extension_name` | The name of the extension. | `VARCHAR` |
+| `loaded` | `true` if the extension is loaded, `false` if it's not loaded. | `BOOLEAN` |
+| `installed` | `true` if the extension is installed, `false` if it's not installed. | `BOOLEAN` |
+| `install_path` | `(BUILT-IN)` if the extension is built-in, otherwise, the filesystem path where binary that implements the extension resides. | `VARCHAR` |
+| `description` | Human readable text that describes the extension's functionality. | `VARCHAR` |
+| `aliases` | List of alternative names for this extension. | `VARCHAR[]` |
+
+## `duckdb_functions`
+
+The `duckdb_functions()` function provides metadata about the functions (including macros) available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains this function. | `VARCHAR` |
+| `schema_name` | The SQL name of the schema where the function resides. | `VARCHAR` |
+| `function_name` | The SQL name of the function. | `VARCHAR` |
+| `function_type` | The function kind. Value is one of: `table`,`scalar`,`aggregate`,`pragma`,`macro`| `VARCHAR` |
+| `description` | Description of this function (always `NULL`)| `VARCHAR` |
+| `return_type` | The logical data type name of the returned value. Applicable for scalar and aggregate functions. | `VARCHAR` |
+| `parameters` | If the function has parameters, the list of parameter names. | `VARCHAR[]` |
+| `parameter_types` | If the function has parameters, a list of logical data type names corresponding to the parameter list. | `VARCHAR[]` |
+| `varargs` | The name of the data type in case the function has a variable number of arguments, or `NULL` if the function does not have a variable number of arguments. | `VARCHAR` |
+| `macro_definition` | If this is a [macro]({% link docs/archive/1.0/sql/statements/create_macro.md %}), the SQL expression that defines it. | `VARCHAR` |
+| `has_side_effects` | `false` if this is a pure function. `true` if this function changes the database state (like sequence functions `nextval()` and `curval()`). | `BOOLEAN` |
+| `function_oid` | The internal identifier for this function | `BIGINT` |
+
+## `duckdb_indexes`
+
+The `duckdb_indexes()` function provides metadata about secondary indexes available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains this index. | `VARCHAR` |
+| `database_oid` | Internal identifier of the database containing the index. | `BIGINT` |
+| `schema_name` | The SQL name of the schema that contains the table with the secondary index. | `VARCHAR` |
+| `schema_oid` | Internal identifier of the schema object. | `BIGINT` |
+| `index_name` | The SQL name of this secondary index. | `VARCHAR` |
+| `index_oid` | The object identifier of this index. | `BIGINT` |
+| `table_name` | The name of the table with the index. | `VARCHAR` |
+| `table_oid` | Internal identifier (name) of the table object. | `BIGINT` |
+| `is_unique` | `true` if the index was created with the `UNIQUE` modifier, `false` if it was not. | `BOOLEAN` |
+| `is_primary` | Always `false`| `BOOLEAN` |
+| `expressions` | Always `NULL`| `VARCHAR` |
+| `sql` | The definition of the index, expressed as a `CREATE INDEX` SQL statement. | `VARCHAR` |
+
+Note that `duckdb_indexes` only provides metadata about secondary indexes – i.e., those indexes created by explicit [`CREATE INDEX`]({% link docs/archive/1.0/sql/indexes.md %}#create-index) statements. Primary keys, foreign keys, and `UNIQUE` constraints are maintained using indexes, but their details are included in the `duckdb_constraints()` function.
+
+## `duckdb_keywords`
+
+The `duckdb_keywords()` function provides metadata about DuckDB's keywords and reserved words.
+
+
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `keyword_name` | The keyword. | `VARCHAR` |
+| `keyword_category` | Indicates the category of the keyword. Values are `column_name`, `reserved`, `type_function` and `unreserved`. | `VARCHAR` |
+
+## `duckdb_memory`
+
+The `duckdb_memory()` function provides metadata about DuckDB's buffer manager.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `tag` | The memory tag. It has one of the following values: `BASE_TABLE`, `HASH_TABLE`, `PARQUET_READER`, `CSV_READER`, `ORDER_BY`, `ART_INDEX`, `COLUMN_DATA`, `METADATA`, `OVERFLOW_STRINGS`, `IN_MEMORY_TABLE`, `ALLOCATOR`, `EXTENSION`. | `VARCHAR` |
+| `memory_usage_bytes` | The memory used (in bytes). | `BIGINT` |
+| `temporary_storage_bytes` | The disk storage used (in bytes). | `BIGINT` |
+
+## `duckdb_optimizers`
+
+The `duckdb_optimizers()` function provides metadata about the optimization rules (e.g., `expression_rewriter`, `filter_pushdown`) available in the DuckDB instance.
+These can be selectively turned off using [`PRAGMA disabled_optimizers`]({% link docs/archive/1.0/configuration/pragmas.md %}#selectively-disabling-optimizers).
+
+
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `name` | The name of the optimization rule. | `VARCHAR` |
+
+## `duckdb_schemas`
+
+The `duckdb_schemas()` function provides metadata about the schemas available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `oid` | Internal identifier of the schema object. | `BIGINT` |
+| `database_name` | The name of the database that contains this schema. | `VARCHAR` |
+| `database_oid` | Internal identifier of the database containing the schema. | `BIGINT` |
+| `schema_name` | The SQL name of the schema. | `VARCHAR` |
+| `internal` | `true` if this is an internal (built-in) schema, `false` if this is a user-defined schema. | `BOOLEAN` |
+| `sql` | Always `NULL`| `VARCHAR` |
+
+The [`information_schema.schemata`]({% link docs/archive/1.0/sql/meta/information_schema.md %}#schemata-database-catalog-and-schema) system view provides a more standardized way to obtain metadata about database schemas.
+
+## `duckdb_secrets`
+
+The `duckdb_secrets()` function provides metadata about the secrets available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `name` | The name of the secret. | `VARCHAR` |
+| `type` | The type of the secret, e.g., `S3`, `GCS`, `R2`, `AZURE`. | `VARCHAR` |
+| `provider` | The provider of the secret. | `VARCHAR` |
+| `persistent` | Denotes whether the secret is persisent. | `BOOLEAN` |
+| `storage` | The backend for storing the secret. | `VARCHAR` |
+| `scope` | The scope of the secret. | `VARCHAR[]` |
+| `secret_string` | Returns the content of the secret as a string. Sensitive pieces of information, e.g., they access key, are redacted. | `VARCHAR` |
+
+## `duckdb_sequences`
+
+The `duckdb_sequences()` function provides metadata about the sequences available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains this sequence | `VARCHAR` |
+| `database_oid` | Internal identifier of the database containing the sequence. | `BIGINT` |
+| `schema_name` | The SQL name of the schema that contains the sequence object. | `VARCHAR` |
+| `schema_oid` | Internal identifier of the schema object that contains the sequence object. | `BIGINT` |
+| `sequence_name` | The SQL name that identifies the sequence within the schema. | `VARCHAR` |
+| `sequence_oid` | The internal identifier of this sequence object. | `BIGINT` |
+| `temporary` | Whether this sequence is temporary. Temporary sequences are transient and only visible within the current connection. | `BOOLEAN` |
+| `start_value` | The initial value of the sequence. This value will be returned when `nextval()` is called for the very first time on this sequence. | `BIGINT` |
+| `min_value` | The minimum value of the sequence. | `BIGINT` |
+| `max_value` | The maximum value of the sequence. | `BIGINT` |
+| `increment_by` | The value that is added to the current value of the sequence to draw the next value from the sequence. | `BIGINT` |
+| `cycle` | Whether the sequence should start over when drawing the next value would result in a value outside the range. | `BOOLEAN` |
+| `last_value` | `null` if no value was ever drawn from the sequence using `nextval(...)`. `1` if a value was drawn. | `BIGINT` |
+| `sql` | The definition of this object, expressed as SQL DDL-statement. | `VARCHAR` |
+
+Attributes like `temporary`, `start_value` etc. correspond to the various options available in the [`CREATE SEQUENCE`]({% link docs/archive/1.0/sql/statements/create_sequence.md %}) statement and are documented there in full. Note that the attributes will always be filled out in the `duckdb_sequences` resultset, even if they were not explicitly specified in the `CREATE SEQUENCE` statement.
+
+> 1. The column name `last_value` suggests that it contains the last value that was drawn from the sequence, but that is not the case. It's either `null` if a value was never drawn from the sequence, or `1` (when there was a value drawn, ever, from the sequence).
+>
+> 2. If the sequence cycles, then the sequence will start over from the boundary of its range, not necessarily from the value specified as start value.
+
+## `duckdb_settings`
+
+The `duckdb_settings()` function provides metadata about the settings available in the DuckDB instance.
+
+
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `name` | Name of the setting. | `VARCHAR` |
+| `value` | Current value of the setting. | `VARCHAR` |
+| `description` | A description of the setting. | `VARCHAR` |
+| `input_type` | The logical datatype of the setting's value. | `VARCHAR` |
+
+The various settings are described in the [configuration page]({% link docs/archive/1.0/configuration/overview.md %}).
+
+## `duckdb_tables`
+
+The `duckdb_tables()` function provides metadata about the base tables available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains this table | `VARCHAR` |
+| `database_oid` | Internal identifier of the database containing the table. | `BIGINT` |
+| `schema_name` | The SQL name of the schema that contains the base table. | `VARCHAR` |
+| `schema_oid` | Internal identifier of the schema object that contains the base table. | `BIGINT` |
+| `table_name` | The SQL name of the base table. | `VARCHAR` |
+| `table_oid` | Internal identifier of the base table object. | `BIGINT` |
+| `internal` | `false` if this is a user-defined table. | `BOOLEAN` |
+| `temporary` | Whether this is a temporary table. Temporary tables are not persisted and only visible within the current connection. | `BOOLEAN` |
+| `has_primary_key` | `true` if this table object defines a `PRIMARY KEY`. | `BOOLEAN` |
+| `estimated_size` | The estimated number of rows in the table. | `BIGINT` |
+| `column_count` | The number of columns defined by this object. | `BIGINT` |
+| `index_count` | The number of indexes associated with this table. This number includes all secondary indexes, as well as internal indexes generated to maintain `PRIMARY KEY` and/or `UNIQUE` constraints. | `BIGINT` |
+| `check_constraint_count` | The number of check constraints active on columns within the table. | `BIGINT` |
+| `sql` | The definition of this object, expressed as SQL [`CREATE TABLE`-statement]({% link docs/archive/1.0/sql/statements/create_table.md %}). | `VARCHAR` |
+
+The [`information_schema.tables`]({% link docs/archive/1.0/sql/meta/information_schema.md %}#tables-tables-and-views) system view provides a more standardized way to obtain metadata about database tables that also includes views. But the resultset returned by `duckdb_tables` contains a few columns that are not included in `information_schema.tables`.
+
+## `duckdb_temporary_files`
+
+The `duckdb_temporary_files()` function provides metadata about the temporary files DuckDB has written to disk, to offload data from memory. This function mostly exists for debugging and testing purposes.
+
+
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `path` | The name of the temporary file. | `VARCHAR` |
+| `size` | The size in bytes of the temporary file. | `BIGINT` |
+
+## `duckdb_types`
+
+The `duckdb_types()` function provides metadata about the data types available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains this schema. | `VARCHAR` |
+| `database_oid` | Internal identifier of the database that contains the data type. | `BIGINT` |
+| `schema_name` | The SQL name of the schema containing the type definition. Always `main`. | `VARCHAR` |
+| `schema_oid` | Internal identifier of the schema object. | `BIGINT` |
+| `type_name` | The name or alias of this data type. | `VARCHAR` |
+| `type_oid` | The internal identifier of the data type object. If `NULL`, then this is an alias of the type (as identified by the value in the `logical_type` column). | `BIGINT` |
+| `type_size` | The number of bytes required to represent a value of this type in memory. | `BIGINT` |
+| `logical_type` | The 'canonical' name of this data type. The same `logical_type` may be referenced by several types having different `type_name`s. | `VARCHAR` |
+| `type_category` | The category to which this type belongs. Data types within the same category generally expose similar behavior when values of this type are used in expression. For example, the `NUMERIC` type_category includes integers, decimals, and floating point numbers. | `VARCHAR` |
+| `internal` | Whether this is an internal (built-in) or a user object. | `BOOLEAN` |
+
+## `duckdb_views`
+
+The `duckdb_views()` function provides metadata about the views available in the DuckDB instance.
+
+| Column | Description | Type |
+|:-|:---|:-|
+| `database_name` | The name of the database that contains this view. | `VARCHAR` |
+| `database_oid` | Internal identifier of the database that contains this view. | `BIGINT` |
+| `schema_name` | The SQL name of the schema where the view resides. | `VARCHAR` |
+| `schema_oid` | Internal identifier of the schema object that contains the view. | `BIGINT` |
+| `view_name` | The SQL name of the view object. | `VARCHAR` |
+| `view_oid` | The internal identifier of this view object. | `BIGINT` |
+| `internal` | `true` if this is an internal (built-in) view, `false` if this is a user-defined view. | `BOOLEAN` |
+| `temporary` | `true` if this is a temporary view. Temporary views are not persistent and are only visible within the current connection. | `BOOLEAN` |
+| `column_count` | The number of columns defined by this view object. | `BIGINT` |
+| `sql` | The definition of this object, expressed as SQL DDL-statement. | `VARCHAR` |
+
+The [`information_schema.tables`]({% link docs/archive/1.0/sql/meta/information_schema.md %}#tables-tables-and-views) system view provides a more standardized way to obtain metadata about database views that also includes base tables. But the resultset returned by `duckdb_views` contains also definitions of internal view objects as well as a few columns that are not included in `information_schema.tables`.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/meta/information_schema.md b/docs/archive/1.0/sql/meta/information_schema.md
new file mode 100644
index 00000000000..026b1c813a3
--- /dev/null
+++ b/docs/archive/1.0/sql/meta/information_schema.md
@@ -0,0 +1,131 @@
+---
+layout: docu
+redirect_from:
+- docs/archive/1.0/sql/information_schema
+title: Information Schema
+---
+
+The views in the `information_schema` are SQL-standard views that describe the catalog entries of the database. These views can be filtered to obtain information about a specific column or table.
+DuckDB's implementation is based on [PostgreSQL's information schema](https://www.postgresql.org/docs/16/infoschema-columns.html).
+
+## Tables
+
+### `character_sets`: Character Sets
+
+| Column | Description | Type | Example |
+|--------|-------------|------|---------|
+| `character_set_catalog` | Currently not implemented – always `NULL`. | `VARCHAR` | `NULL` |
+| `character_set_schema` | Currently not implemented – always `NULL`. | `VARCHAR` | `NULL` |
+| `character_set_name` | Name of the character set, currently implemented as showing the name of the database encoding. | `VARCHAR` | `'UTF8'` |
+| `character_repertoire` | Character repertoire, showing `UCS` if the encoding is `UTF8`, else just the encoding name. | `VARCHAR` | `'UCS'` |
+| `form_of_use` | Character encoding form, same as the database encoding. | `VARCHAR` | `'UTF8'` |
+| `default_collate_catalog`| Name of the database containing the default collation (always the current database). | `VARCHAR` | `'my_db'` |
+| `default_collate_schema` | Name of the schema containing the default collation. | `VARCHAR` | `'pg_catalog'` |
+| `default_collate_name` | Name of the default collation. | `VARCHAR` | `'ucs_basic'` |
+
+### `columns`: Columns
+
+The view that describes the catalog information for columns is `information_schema.columns`. It lists the column present in the database and has the following layout:
+
+| Column | Description | Type | Example |
+|:--|:---|:-|:-|
+| `table_catalog` | Name of the database containing the table (always the current database). | `VARCHAR` | `'my_db'` |
+| `table_schema` | Name of the schema containing the table. | `VARCHAR` | `'main'` |
+| `table_name` | Name of the table. | `VARCHAR` | `'widgets'` |
+| `column_name` | Name of the column. | `VARCHAR` | `'price'` |
+| `ordinal_position` | Ordinal position of the column within the table (count starts at 1). | `INTEGER` | `5` |
+| `column_default` | Default expression of the column. |`VARCHAR`| `1.99` |
+| `is_nullable` | `YES` if the column is possibly nullable, `NO` if it is known not nullable. |`VARCHAR`| `'YES'` |
+| `data_type` | Data type of the column. |`VARCHAR`| `'DECIMAL(18, 2)'` |
+| `character_maximum_length` | If `data_type` identifies a character or bit string type, the declared maximum length; null for all other data types or if no maximum length was declared. |`INTEGER`| `255` |
+| `character_octet_length` | If `data_type` identifies a character type, the maximum possible length in octets (bytes) of a datum; null for all other data types. The maximum octet length depends on the declared character maximum length (see above) and the character encoding. |`INTEGER`| `1073741824` |
+| `numeric_precision` | If `data_type` identifies a numeric type, this column contains the (declared or implicit) precision of the type for this column. The precision indicates the number of significant digits. For all other data types, this column is null. |`INTEGER`| `18` |
+| `numeric_scale` | If `data_type` identifies a numeric type, this column contains the (declared or implicit) scale of the type for this column. The precision indicates the number of significant digits. For all other data types, this column is null. |`INTEGER`| `2` |
+| `datetime_precision` | If `data_type` identifies a date, time, timestamp, or interval type, this column contains the (declared or implicit) fractional seconds precision of the type for this column, that is, the number of decimal digits maintained following the decimal point in the seconds value. No fractional seconds are currently supported in DuckDB. For all other data types, this column is null. |`INTEGER`| `0` |
+
+### `key_column_usage`: Key Column Usage
+
+| Column | Description | Type | Example |
+|--------|-------------|------|---------|
+| `constraint_catalog` | Name of the database that contains the constraint (always the current database). | `VARCHAR` | `'my_db'` |
+| `constraint_schema` | Name of the schema that contains the constraint. | `VARCHAR` | `'main'` |
+| `constraint_name` | Name of the constraint. | `VARCHAR` | `'exams_exam_id_fkey'` |
+| `table_catalog` | Name of the database that contains the table that contains the column that is restricted by this constraint (always the current database). | `VARCHAR` | `'my_db'` |
+| `table_schema` | Name of the schema that contains the table that contains the column that is restricted by this constraint. | `VARCHAR` | `'main'` |
+| `table_name` | Name of the table that contains the column that is restricted by this constraint. | `VARCHAR` | `'exams'` |
+| `column_name` | Name of the column that is restricted by this constraint. | `VARCHAR` | `'exam_id'` |
+| `ordinal_position` | Ordinal position of the column within the constraint key (count starts at 1). | `INTEGER` | `1` |
+| `position_in_unique_constraint` | For a foreign-key constraint, ordinal position of the referenced column within its unique constraint (count starts at `1`); otherwise `NULL`. | `INTEGER` | `1` |
+
+### `referential_constraints`: Referential Constraints
+
+| Column | Description | Type | Example |
+|--------|-------------|------|---------|
+| `constraint_catalog` | Name of the database containing the constraint (always the current database). | `VARCHAR` | `'my_db'` |
+| `constraint_schema` | Name of the schema containing the constraint. | `VARCHAR` | `main` |
+| `constraint_name` | Name of the constraint. | `VARCHAR` | `exam_id_students_id_fkey` |
+| `unique_constraint_catalog` | Name of the database that contains the unique or primary key constraint that the foreign key constraint references. | `VARCHAR` | `'my_db'` |
+| `unique_constraint_schema` | Name of the schema that contains the unique or primary key constraint that the foreign key constraint references. | `VARCHAR` | `'main'` |
+| `unique_constraint_name` | Name of the unique or primary key constraint that the foreign key constraint references. | `VARCHAR` | `'students_id_pkey'` |
+| `match_option` | Match option of the foreign key constraint. Always `NONE`. | `VARCHAR` | `NONE` |
+| `update_rule` | Update rule of the foreign key constraint. Always `NO ACTION`. | `VARCHAR` | `NO ACTION` |
+| `delete_rule` | Delete rule of the foreign key constraint. Always `NO ACTION`. | `VARCHAR` | `NO ACTION` |
+
+### `schemata`: Database, Catalog and Schema
+
+The top level catalog view is `information_schema.schemata`. It lists the catalogs and the schemas present in the database and has the following layout:
+
+| Column | Description | Type | Example |
+|:--|:---|:-|:-|
+| `catalog_name` | Name of the database that the schema is contained in. | `VARCHAR` | `'my_db'` |
+| `schema_name` | Name of the schema. | `VARCHAR` | `'main'` |
+| `schema_owner` | Name of the owner of the schema. Not yet implemented. | `VARCHAR` | `'duckdb'` |
+| `default_character_set_catalog` | Applies to a feature not available in DuckDB. | `VARCHAR` | `NULL` |
+| `default_character_set_schema` | Applies to a feature not available in DuckDB. | `VARCHAR` | `NULL` |
+| `default_character_set_name` | Applies to a feature not available in DuckDB. | `VARCHAR` | `NULL` |
+| `sql_path` | The file system location of the database. Currently unimplemented. | `VARCHAR` | `NULL` |
+
+### `tables`: Tables and Views
+
+The view that describes the catalog information for tables and views is `information_schema.tables`. It lists the tables present in the database and has the following layout:
+
+| Column | Description | Type | Example |
+|:--|:---|:-|:-|
+| `table_catalog` | The catalog the table or view belongs to. | `VARCHAR` | `'my_db'` |
+| `table_schema` | The schema the table or view belongs to. | `VARCHAR` | `'main'` |
+| `table_name` | The name of the table or view. | `VARCHAR` | `'widgets'` |
+| `table_type` | The type of table. One of: `BASE TABLE`, `LOCAL TEMPORARY`, `VIEW`. | `VARCHAR` | `'BASE TABLE'` |
+| `self_referencing_column_name` | Applies to a feature not available in DuckDB. | `VARCHAR` | `NULL` |
+| `reference_generation` | Applies to a feature not available in DuckDB. | `VARCHAR` | `NULL` |
+| `user_defined_type_catalog` | If the table is a typed table, the name of the database that contains the underlying data type (always the current database), else null. Currently unimplemented. | `VARCHAR` | `NULL` |
+| `user_defined_type_schema` | If the table is a typed table, the name of the schema that contains the underlying data type, else null. Currently unimplemented. | `VARCHAR` | `NULL` |
+| `user_defined_type_name` | If the table is a typed table, the name of the underlying data type, else null. Currently unimplemented. | `VARCHAR` | `NULL` |
+| `is_insertable_into` | `YES` if the table is insertable into, `NO` if not (Base tables are always insertable into, views not necessarily.)| `VARCHAR` | `'YES'` |
+| `is_typed` | `YES` if the table is a typed table, `NO` if not. | `VARCHAR` | `'NO'` |
+| `commit_action` | Not yet implemented. | `VARCHAR` | `'NO'` |
+
+### `table_constraints`: Table Constraints
+
+| Column | Description | Type | Example |
+|--------|-------------|------|---------|
+| `constraint_catalog` | Name of the database that contains the constraint (always the current database). | `VARCHAR` | `'my_db'` |
+| `constraint_schema` | Name of the schema that contains the constraint. | `VARCHAR` | `'main'` |
+| `constraint_name` | Name of the constraint. | `VARCHAR` | `'exams_exam_id_fkey'` |
+| `table_catalog` | Name of the database that contains the table (always the current database). | `VARCHAR` | `'my_db'` |
+| `table_schema` | Name of the schema that contains the table. | `VARCHAR` | `'main'` |
+| `table_name` | Name of the table. | `VARCHAR` | `'exams'` |
+| `constraint_type` | Type of the constraint: `CHECK`, `FOREIGN KEY`, `PRIMARY KEY`, or `UNIQUE`. | `VARCHAR` | `'FOREIGN KEY'` |
+| `is_deferrable` | `YES` if the constraint is deferrable, `NO` if not. | `VARCHAR` | `'NO'` |
+| `initially_deferred` | `YES` if the constraint is deferrable and initially deferred, `NO` if not. | `VARCHAR` | `'NO'` |
+| `enforced` | Always `YES`. | `VARCHAR` | `'YES'` |
+| `nulls_distinct` | If the constraint is a unique constraint, then `YES` if the constraint treats nulls as distinct or `NO` if it treats nulls as not distinct, otherwise `NULL` for other types of constraints. | `VARCHAR` | `'YES'` |
+
+## Catalog Functions
+
+Several functions are also provided to see details about the catalogs and schemas that are configured in the database.
+
+| Function | Description | Example | Result |
+|:--|:---|:--|:--|
+| `current_catalog()` | Return the name of the currently active catalog. Default is memory. | `current_catalog()` | `'memory'` |
+| `current_schema()` | Return the name of the currently active schema. Default is main. | `current_schema()` | `'main'` |
+| `current_schemas(boolean)` | Return list of schemas. Pass a parameter of `true` to include implicit schemas. | `current_schemas(true)` | `['temp', 'main', 'pg_catalog']` |
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/filter.md b/docs/archive/1.0/sql/query_syntax/filter.md
new file mode 100644
index 00000000000..e8640436704
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/filter.md
@@ -0,0 +1,143 @@
+---
+layout: docu
+railroad: query_syntax/filter.js
+title: FILTER Clause
+---
+
+The `FILTER` clause may optionally follow an aggregate function in a `SELECT` statement. This will filter the rows of data that are fed into the aggregate function in the same way that a `WHERE` clause filters rows, but localized to the specific aggregate function. `FILTER`s are not currently able to be used when the aggregate function is in a windowing context.
+
+There are multiple types of situations where this is useful, including when evaluating multiple aggregates with different filters, and when creating a pivoted view of a dataset. `FILTER` provides a cleaner syntax for pivoting data when compared with the more traditional `CASE WHEN` approach discussed below.
+
+Some aggregate functions also do not filter out null values, so using a `FILTER` clause will return valid results when at times the `CASE WHEN` approach will not. This occurs with the functions `first` and `last`, which are desirable in a non-aggregating pivot operation where the goal is to simply re-orient the data into columns rather than re-aggregate it. `FILTER` also improves null handling when using the `list` and `array_agg` functions, as the `CASE WHEN` approach will include null values in the list result, while the `FILTER` clause will remove them.
+
+## Examples
+
+Return the following:
+
+* The total number of rows.
+* The number of rows where `i <= 5`
+* The number of rows where `i` is odd
+
+```sql
+SELECT
+ count(*) AS total_rows,
+ count(*) FILTER (i <= 5) AS lte_five,
+ count(*) FILTER (i % 2 = 1) AS odds
+FROM generate_series(1, 10) tbl(i);
+```
+
+
+
+| total_rows | lte_five | odds |
+|:---|:---|:---|
+| 10 | 5 | 5 |
+
+Different aggregate functions may be used, and multiple `WHERE` expressions are also permitted:
+
+```sql
+SELECT
+ sum(i) FILTER (i <= 5) AS lte_five_sum,
+ median(i) FILTER (i % 2 = 1) AS odds_median,
+ median(i) FILTER (i % 2 = 1 AND i <= 5) AS odds_lte_five_median
+FROM generate_series(1, 10) tbl(i);
+```
+
+
+
+| lte_five_sum | odds_median | odds_lte_five_median |
+|:---|:---|:---|
+| 15 | 5.0 | 3.0 |
+
+The `FILTER` clause can also be used to pivot data from rows into columns. This is a static pivot, as columns must be defined prior to runtime in SQL. However, this kind of statement can be dynamically generated in a host programming language to leverage DuckDB's SQL engine for rapid, larger than memory pivoting.
+
+First generate an example dataset:
+
+```sql
+CREATE TEMP TABLE stacked_data AS
+ SELECT
+ i,
+ CASE WHEN i <= rows * 0.25 THEN 2022
+ WHEN i <= rows * 0.5 THEN 2023
+ WHEN i <= rows * 0.75 THEN 2024
+ WHEN i <= rows * 0.875 THEN 2025
+ ELSE NULL
+ END AS year
+ FROM (
+ SELECT
+ i,
+ count(*) OVER () AS rows
+ FROM generate_series(1, 100_000_000) tbl(i)
+ ) tbl;
+```
+
+“Pivot” the data out by year (move each year out to a separate column):
+
+```sql
+SELECT
+ count(i) FILTER (year = 2022) AS "2022",
+ count(i) FILTER (year = 2023) AS "2023",
+ count(i) FILTER (year = 2024) AS "2024",
+ count(i) FILTER (year = 2025) AS "2025",
+ count(i) FILTER (year IS NULL) AS "NULLs"
+FROM stacked_data;
+```
+
+This syntax produces the same results as the `FILTER` clauses above:
+
+```sql
+SELECT
+ count(CASE WHEN year = 2022 THEN i END) AS "2022",
+ count(CASE WHEN year = 2023 THEN i END) AS "2023",
+ count(CASE WHEN year = 2024 THEN i END) AS "2024",
+ count(CASE WHEN year = 2025 THEN i END) AS "2025",
+ count(CASE WHEN year IS NULL THEN i END) AS "NULLs"
+FROM stacked_data;
+```
+
+
+
+| 2022 | 2023 | 2024 | 2025 | NULLs |
+|:---|:---|:---|:---|:---|
+| 25000000 | 25000000 | 25000000 | 12500000 | 12500000 |
+
+However, the `CASE WHEN` approach will not work as expected when using an aggregate function that does not ignore `NULL` values. The `first` function falls into this category, so `FILTER` is preferred in this case.
+
+“Pivot” the data out by year (move each year out to a separate column):
+
+```sql
+SELECT
+ first(i) FILTER (year = 2022) AS "2022",
+ first(i) FILTER (year = 2023) AS "2023",
+ first(i) FILTER (year = 2024) AS "2024",
+ first(i) FILTER (year = 2025) AS "2025",
+ first(i) FILTER (year IS NULL) AS "NULLs"
+FROM stacked_data;
+```
+
+
+
+| 2022 | 2023 | 2024 | 2025 | NULLs |
+|:---|:---|:---|:---|:---|
+| 1474561 | 25804801 | 50749441 | 76431361 | 87500001 |
+
+This will produce `NULL` values whenever the first evaluation of the `CASE WHEN` clause returns a `NULL`:
+
+```sql
+SELECT
+ first(CASE WHEN year = 2022 THEN i END) AS "2022",
+ first(CASE WHEN year = 2023 THEN i END) AS "2023",
+ first(CASE WHEN year = 2024 THEN i END) AS "2024",
+ first(CASE WHEN year = 2025 THEN i END) AS "2025",
+ first(CASE WHEN year IS NULL THEN i END) AS "NULLs"
+FROM stacked_data;
+```
+
+
+
+| 2022 | 2023 | 2024 | 2025 | NULLs |
+|:---|:---|:---|:---|:---|
+| 1228801 | NULL | NULL | NULL | NULL |
+
+## Aggregate Function Syntax (Including `FILTER` Clause)
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/from.md b/docs/archive/1.0/sql/query_syntax/from.md
new file mode 100644
index 00000000000..542451e23ef
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/from.md
@@ -0,0 +1,534 @@
+---
+blurb: The FROM clause can contain a single table, a combination of multiple tables
+ that are joined together, or another SELECT query inside a subquery node.
+layout: docu
+railroad: query_syntax/from.js
+title: FROM & JOIN Clauses
+---
+
+The `FROM` clause specifies the *source* of the data on which the remainder of the query should operate. Logically, the `FROM` clause is where the query starts execution. The `FROM` clause can contain a single table, a combination of multiple tables that are joined together using `JOIN` clauses, or another `SELECT` query inside a subquery node. DuckDB also has an optional `FROM`-first syntax which enables you to also query without a `SELECT` statement.
+
+## Examples
+
+Select all columns from the table called `table_name`:
+
+```sql
+SELECT *
+FROM table_name;
+```
+
+Select all columns from the table using the `FROM`-first syntax:
+
+```sql
+FROM table_name
+SELECT *;
+```
+
+Select all columns using the `FROM`-first syntax and omitting the `SELECT` clause:
+
+```sql
+FROM table_name;
+```
+
+Select all columns from the table called `table_name` through an alias `tn`:
+
+```sql
+SELECT tn.*
+FROM table_name tn;
+```
+
+Select all columns from the table `table_name` in the schema `schema_name`:
+
+```sql
+SELECT *
+FROM schema_name.table_name;
+```
+
+Select the column `i` from the table function `range`, where the first column of the range function is renamed to `i`:
+
+```sql
+SELECT t.i
+FROM range(100) AS t(i);
+```
+
+Select all columns from the CSV file called `test.csv`:
+
+```sql
+SELECT *
+FROM 'test.csv';
+```
+
+Select all columns from a subquery:
+
+```sql
+SELECT *
+FROM (SELECT * FROM table_name);
+```
+
+Select the entire row of the table as a struct:
+
+```sql
+SELECT t
+FROM t;
+```
+
+Select the entire row of the subquery as a struct (i.e., a single column):
+
+```sql
+SELECT t
+FROM (SELECT unnest(generate_series(41, 43)) AS x, 'hello' AS y) t;
+```
+
+Join two tables together:
+
+```sql
+SELECT *
+FROM table_name
+JOIN other_table
+ ON table_name.key = other_table.key;
+```
+
+Select a 10% sample from a table:
+
+```sql
+SELECT *
+FROM table_name
+TABLESAMPLE 10%;
+```
+
+Select a sample of 10 rows from a table:
+
+```sql
+SELECT *
+FROM table_name
+TABLESAMPLE 10 ROWS;
+```
+
+Use the `FROM`-first syntax with `WHERE` clause and aggregation:
+
+```sql
+FROM range(100) AS t(i)
+SELECT sum(t.i)
+WHERE i % 2 = 0;
+```
+
+## Joins
+
+Joins are a fundamental relational operation used to connect two tables or relations horizontally.
+The relations are referred to as the _left_ and _right_ sides of the join
+based on how they are written in the join clause.
+Each result row has the columns from both relations.
+
+A join uses a rule to match pairs of rows from each relation.
+Often this is a predicate, but there are other implied rules that may be specified.
+
+### Outer Joins
+
+Rows that do not have any matches can still be returned if an `OUTER` join is specified.
+Outer joins can be one of:
+
+* `LEFT` (All rows from the left relation appear at least once)
+* `RIGHT` (All rows from the right relation appear at least once)
+* `FULL` (All rows from both relations appear at least once)
+
+A join that is not `OUTER` is `INNER` (only rows that get paired are returned).
+
+When an unpaired row is returned, the attributes from the other table are set to `NULL`.
+
+### Cross Product Joins (Cartesian Product)
+
+The simplest type of join is a `CROSS JOIN`.
+There are no conditions for this type of join,
+and it just returns all the possible pairs.
+
+Return all pairs of rows:
+
+```sql
+SELECT a.*, b.*
+FROM a
+CROSS JOIN b;
+```
+
+This is equivalent to omitting the `JOIN` clause:
+
+```sql
+SELECT a.*, b.*
+FROM a, b;
+```
+
+### Conditional Joins
+
+Most joins are specified by a predicate that connects
+attributes from one side to attributes from the other side.
+The conditions can be explicitly specified using an `ON` clause
+with the join (clearer) or implied by the `WHERE` clause (old-fashioned).
+
+We use the `l_regions` and the `l_nations` tables from the TPC-H schema:
+
+```sql
+CREATE TABLE l_regions (
+ r_regionkey INTEGER NOT NULL PRIMARY KEY,
+ r_name CHAR(25) NOT NULL,
+ r_comment VARCHAR(152)
+);
+
+CREATE TABLE l_nations (
+ n_nationkey INTEGER NOT NULL PRIMARY KEY,
+ n_name CHAR(25) NOT NULL,
+ n_regionkey INTEGER NOT NULL,
+ n_comment VARCHAR(152),
+ FOREIGN KEY (n_regionkey) REFERENCES l_regions(r_regionkey)
+);
+```
+
+Return the regions for the nations:
+
+```sql
+SELECT n.*, r.*
+FROM l_nations n
+JOIN l_regions r ON (n_regionkey = r_regionkey);
+```
+
+If the column names are the same and are required to be equal,
+then the simpler `USING` syntax can be used:
+
+```sql
+CREATE TABLE l_regions (regionkey INTEGER NOT NULL PRIMARY KEY,
+ name CHAR(25) NOT NULL,
+ comment VARCHAR(152));
+
+CREATE TABLE l_nations (nationkey INTEGER NOT NULL PRIMARY KEY,
+ name CHAR(25) NOT NULL,
+ regionkey INTEGER NOT NULL,
+ comment VARCHAR(152),
+ FOREIGN KEY (regionkey) REFERENCES l_regions(regionkey));
+```
+
+Return the regions for the nations:
+
+```sql
+SELECT n.*, r.*
+FROM l_nations n
+JOIN l_regions r USING (regionkey);
+```
+
+The expressions do not have to be equalities – any predicate can be used:
+
+Return the pairs of jobs where one ran longer but cost less:
+
+```sql
+SELECT s1.t_id, s2.t_id
+FROM west s1, west s2
+WHERE s1.time > s2.time
+ AND s1.cost < s2.cost;
+```
+
+### Natural Joins
+
+Natural joins join two tables based on attributes that share the same name.
+
+For example, take the following example with cities, airport codes and airport names. Note that both tables are intentionally incomplete, i.e., they do not have a matching pair in the other table.
+
+```sql
+CREATE TABLE city_airport (city_name VARCHAR, iata VARCHAR);
+CREATE TABLE airport_names (iata VARCHAR, airport_name VARCHAR);
+INSERT INTO city_airport VALUES
+ ('Amsterdam', 'AMS'),
+ ('Rotterdam', 'RTM'),
+ ('Eindhoven', 'EIN'),
+ ('Groningen', 'GRQ');
+INSERT INTO airport_names VALUES
+ ('AMS', 'Amsterdam Airport Schiphol'),
+ ('RTM', 'Rotterdam The Hague Airport'),
+ ('MST', 'Maastricht Aachen Airport');
+```
+
+To join the tables on their shared [`IATA`](https://en.wikipedia.org/wiki/IATA_airport_code) attributes, run:
+
+```sql
+SELECT *
+FROM city_airport
+NATURAL JOIN airport_names;
+```
+
+This produces the following result:
+
+| city_name | iata | airport_name |
+|-----------|------|-----------------------------|
+| Amsterdam | AMS | Amsterdam Airport Schiphol |
+| Rotterdam | RTM | Rotterdam The Hague Airport |
+
+Note that only rows where the same `iata` attribute was present in both tables were included in the result.
+
+We can also express query using the vanilla `JOIN` clause with the `USING` keyword:
+
+```sql
+SELECT *
+FROM city_airport
+JOIN airport_names
+USING (iata);
+```
+
+### Semi and Anti Joins
+
+Semi joins return rows from the left table that have at least one match in the right table.
+Anti joins return rows from the left table that have _no_ matches in the right table.
+When using a semi or anti join the result will never have more rows than the left hand side table.
+Semi and anti joins provide the same logic as [`IN`]({% link docs/archive/1.0/sql/expressions/in.md %}) and `NOT IN` statements, respectively.
+
+#### Semi Join Example
+
+Return a list of city–airport code pairs from the `city_airport` table where the airport name **is available** in the `airport_names` table:
+
+```sql
+SELECT *
+FROM city_airport
+SEMI JOIN airport_names
+ USING (iata);
+```
+
+| city_name | iata |
+|-----------|------|
+| Amsterdam | AMS |
+| Rotterdam | RTM |
+
+This query is equivalent with:
+
+```sql
+SELECT *
+FROM city_airport
+WHERE iata IN (SELECT iata FROM airport_names);
+```
+
+#### Anti Join Example
+
+Return a list of city–airport code pairs from the `city_airport` table where the airport name **is not available** in the `airport_names` table:
+
+```sql
+SELECT *
+FROM city_airport
+ANTI JOIN airport_names
+ USING (iata);
+```
+
+| city_name | iata |
+|-----------|------|
+| Eindhoven | EIN |
+| Groningen | GRQ |
+
+This query is equivalent with:
+
+```sql
+SELECT *
+FROM city_airport
+WHERE iata NOT IN (SELECT iata FROM airport_names);
+```
+
+### Lateral Joins
+
+The `LATERAL` keyword allows subqueries in the `FROM` clause to refer to previous subqueries. This feature is also known as a _lateral join_.
+
+```sql
+SELECT *
+FROM range(3) t(i), LATERAL (SELECT i + 1) t2(j);
+```
+
+| i | j |
+|--:|--:|
+| 0 | 1 |
+| 2 | 3 |
+| 1 | 2 |
+
+Lateral joins are a generalization of correlated subqueries, as they can return multiple values per input value rather than only a single value.
+
+```sql
+SELECT *
+FROM
+ generate_series(0, 1) t(i),
+ LATERAL (SELECT i + 10 UNION ALL SELECT i + 100) t2(j);
+```
+
+| i | j |
+|--:|----:|
+| 0 | 10 |
+| 1 | 11 |
+| 0 | 100 |
+| 1 | 101 |
+
+It may be helpful to think about `LATERAL` as a loop where we iterate through the rows of the first subquery and use it as input to the second (`LATERAL`) subquery.
+In the examples above, we iterate through table `t` and refer to its column `i` from the definition of table `t2`. The rows of `t2` form column `j` in the result.
+
+It is possible to refer to multiple attributes from the `LATERAL` subquery. Using the table from the first example:
+
+```sql
+CREATE TABLE t1 AS
+ SELECT *
+ FROM range(3) t(i), LATERAL (SELECT i + 1) t2(j);
+
+SELECT *
+ FROM t1, LATERAL (SELECT i + j) t2(k)
+ ORDER BY ALL;
+```
+
+| i | j | k |
+|--:|--:|--:|
+| 0 | 1 | 1 |
+| 1 | 2 | 3 |
+| 2 | 3 | 5 |
+
+> DuckDB detects when `LATERAL` joins should be used, making the use of the `LATERAL` keyword optional.
+
+### Positional Joins
+
+When working with data frames or other embedded tables of the same size,
+the rows may have a natural correspondence based on their physical order.
+In scripting languages, this is easily expressed using a loop:
+
+```cpp
+for (i = 0; i < n; i++) {
+ f(t1.a[i], t2.b[i]);
+}
+```
+
+It is difficult to express this in standard SQL because
+relational tables are not ordered, but imported tables such as [data frames]({% link docs/archive/1.0/api/python/data_ingestion.md %}#pandas-dataframes-–-object-columns)
+or disk files (like [CSVs]({% link docs/archive/1.0/data/csv/overview.md %}) or [Parquet files]({% link docs/archive/1.0/data/parquet/overview.md %})) do have a natural ordering.
+
+Connecting them using this ordering is called a _positional join:_
+
+```sql
+CREATE TABLE t1 (x INTEGER);
+CREATE TABLE t2 (s VARCHAR);
+
+INSERT INTO t1 VALUES (1), (2), (3);
+INSERT INTO t2 VALUES ('a'), ('b');
+
+SELECT *
+FROM t1
+POSITIONAL JOIN t2;
+```
+
+| x | s |
+|--:|------|
+| 1 | a |
+| 2 | b |
+| 3 | NULL |
+
+Positional joins are always `FULL OUTER` joins, i.e., missing values (the last values in the shorter column) are set to `NULL`.
+
+### As-Of Joins
+
+A common operation when working with temporal or similarly-ordered data
+is to find the nearest (first) event in a reference table (such as prices).
+This is called an _as-of join:_
+
+Attach prices to stock trades:
+
+```sql
+SELECT t.*, p.price
+FROM trades t
+ASOF JOIN prices p
+ ON t.symbol = p.symbol AND t.when >= p.when;
+```
+
+The `ASOF` join requires at least one inequality condition on the ordering field.
+The inequality can be any inequality condition (`>=`, `>`, `<=`, `<`)
+on any data type, but the most common form is `>=` on a temporal type.
+Any other conditions must be equalities (or `NOT DISTINCT`).
+This means that the left/right order of the tables is significant.
+
+`ASOF` joins each left side row with at most one right side row.
+It can be specified as an `OUTER` join to find unpaired rows
+(e.g., trades without prices or prices which have no trades.)
+
+Attach prices or NULLs to stock trades:
+
+```sql
+SELECT *
+FROM trades t
+ASOF LEFT JOIN prices p
+ ON t.symbol = p.symbol
+ AND t.when >= p.when;
+```
+
+`ASOF` joins can also specify join conditions on matching column names with the `USING` syntax,
+but the *last* attribute in the list must be the inequality,
+which will be greater than or equal to (`>=`):
+
+```sql
+SELECT *
+FROM trades t
+ASOF JOIN prices p USING (symbol, "when");
+```
+
+Returns symbol, trades.when, price (but NOT prices.when):
+
+If you combine `USING` with a `SELECT *` like this,
+the query will return the left side (probe) column values for the matches,
+not the right side (build) column values.
+To get the `prices` times in the example, you will need to list the columns explicitly:
+
+```sql
+SELECT t.symbol, t.when AS trade_when, p.when AS price_when, price
+FROM trades t
+ASOF LEFT JOIN prices p USING (symbol, "when");
+```
+
+## `FROM`-First Syntax
+
+DuckDB's SQL supports the `FROM`-first syntax, i.e., it allows putting the `FROM` clause before the `SELECT` clause or completely omitting the `SELECT` clause. We use the following example to demonstrate it:
+
+```sql
+CREATE TABLE tbl AS
+ SELECT *
+ FROM (VALUES ('a'), ('b')) t1(s), range(1, 3) t2(i);
+```
+
+### `FROM`-First Syntax with a `SELECT` Clause
+
+The following statement demonstrates the use of the `FROM`-first syntax:
+
+```sql
+FROM tbl
+SELECT i, s;
+```
+
+This is equivalent to:
+
+```sql
+SELECT i, s
+FROM tbl;
+```
+
+| i | s |
+|--:|---|
+| 1 | a |
+| 2 | a |
+| 1 | b |
+| 2 | b |
+
+### `FROM`-First Syntax without a `SELECT` Clause
+
+The following statement demonstrates the use of the optional `SELECT` clause:
+
+```sql
+FROM tbl;
+```
+
+This is equivalent to:
+
+```sql
+SELECT *
+FROM tbl;
+```
+
+| s | i |
+|---|--:|
+| a | 1 |
+| a | 2 |
+| b | 1 |
+| b | 2 |
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/groupby.md b/docs/archive/1.0/sql/query_syntax/groupby.md
new file mode 100644
index 00000000000..017f083df4f
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/groupby.md
@@ -0,0 +1,64 @@
+---
+layout: docu
+railroad: query_syntax/groupby.js
+title: GROUP BY Clause
+---
+
+The `GROUP BY` clause specifies which grouping columns should be used to perform any aggregations in the `SELECT` clause.
+If the `GROUP BY` clause is specified, the query is always an aggregate query, even if no aggregations are present in the `SELECT` clause.
+
+When a `GROUP BY` clause is specified, all tuples that have matching data in the grouping columns (i.e., all tuples that belong to the same group) will be combined.
+The values of the grouping columns themselves are unchanged, and any other columns can be combined using an [aggregate function]({% link docs/archive/1.0/sql/functions/aggregates.md %}) (such as `count`, `sum`, `avg`, etc).
+
+## `GROUP BY ALL`
+
+Use `GROUP BY ALL` to `GROUP BY` all columns in the `SELECT` statement that are not wrapped in aggregate functions.
+This simplifies the syntax by allowing the columns list to be maintained in a single location, and prevents bugs by keeping the `SELECT` granularity aligned to the `GROUP BY` granularity (Ex: Prevents any duplication).
+See examples below and additional examples in the [“Friendlier SQL with DuckDB” blog post]({% post_url 2022-05-04-friendlier-sql %}#group-by-all).
+
+## Multiple Dimensions
+
+Normally, the `GROUP BY` clause groups along a single dimension.
+Using the [`GROUPING SETS`, `CUBE` or `ROLLUP` clauses]({% link docs/archive/1.0/sql/query_syntax/grouping_sets.md %}) it is possible to group along multiple dimensions.
+See the [`GROUPING SETS`]({% link docs/archive/1.0/sql/query_syntax/grouping_sets.md %}) page for more information.
+
+## Examples
+
+Count the number of entries in the `addresses` table that belong to each different city:
+
+```sql
+SELECT city, count(*)
+FROM addresses
+GROUP BY city;
+```
+
+Compute the average income per city per street_name:
+
+```sql
+SELECT city, street_name, avg(income)
+FROM addresses
+GROUP BY city, street_name;
+```
+
+### `GROUP BY ALL` Examples
+
+Group by city and street_name to remove any duplicate values:
+
+```sql
+SELECT city, street_name
+FROM addresses
+GROUP BY ALL;
+```
+
+Compute the average income per city per street_name. Since income is wrapped in an aggregate function, do not include it in the `GROUP BY`:
+
+```sql
+SELECT city, street_name, avg(income)
+FROM addresses
+GROUP BY ALL;
+-- GROUP BY city, street_name:
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/grouping_sets.md b/docs/archive/1.0/sql/query_syntax/grouping_sets.md
new file mode 100644
index 00000000000..6c4689cfddc
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/grouping_sets.md
@@ -0,0 +1,213 @@
+---
+layout: docu
+railroad: query_syntax/groupby.js
+title: GROUPING SETS
+---
+
+`GROUPING SETS`, `ROLLUP` and `CUBE` can be used in the `GROUP BY` clause to perform a grouping over multiple dimensions within the same query.
+Note that this syntax is not compatible with [`GROUP BY ALL`]({% link docs/archive/1.0/sql/query_syntax/groupby.md %}#group-by-all).
+
+## Examples
+
+Compute the average income along the provided four different dimensions:
+
+```sql
+-- the syntax () denotes the empty set (i.e., computing an ungrouped aggregate)
+SELECT city, street_name, avg(income)
+FROM addresses
+GROUP BY GROUPING SETS ((city, street_name), (city), (street_name), ());
+```
+
+Compute the average income along the same dimensions:
+
+```sql
+SELECT city, street_name, avg(income)
+FROM addresses
+GROUP BY CUBE (city, street_name);
+```
+
+Compute the average income along the dimensions `(city, street_name)`, `(city)` and `()`:
+
+```sql
+SELECT city, street_name, avg(income)
+FROM addresses
+GROUP BY ROLLUP (city, street_name);
+```
+
+## Description
+
+`GROUPING SETS` perform the same aggregate across different `GROUP BY clauses` in a single query.
+
+```sql
+CREATE TABLE students (course VARCHAR, type VARCHAR);
+INSERT INTO students (course, type)
+VALUES
+ ('CS', 'Bachelor'), ('CS', 'Bachelor'), ('CS', 'PhD'), ('Math', 'Masters'),
+ ('CS', NULL), ('CS', NULL), ('Math', NULL);
+```
+
+```sql
+SELECT course, type, count(*)
+FROM students
+GROUP BY GROUPING SETS ((course, type), course, type, ());
+```
+
+| course | type | count_star() |
+|--------|----------|-------------:|
+| Math | NULL | 1 |
+| NULL | NULL | 7 |
+| CS | PhD | 1 |
+| CS | Bachelor | 2 |
+| Math | Masters | 1 |
+| CS | NULL | 2 |
+| Math | NULL | 2 |
+| CS | NULL | 5 |
+| NULL | NULL | 3 |
+| NULL | Masters | 1 |
+| NULL | Bachelor | 2 |
+| NULL | PhD | 1 |
+
+In the above query, we group across four different sets: `course, type`, `course`, `type` and `()` (the empty group). The result contains `NULL` for a group which is not in the grouping set for the result, i.e., the above query is equivalent to the following UNION statement:
+
+Group by course, type:
+
+```sql
+SELECT course, type, count(*)
+FROM students
+GROUP BY course, type
+UNION ALL
+```
+
+Group by type:
+
+```sql
+SELECT NULL AS course, type, count(*)
+FROM students
+GROUP BY type
+UNION ALL
+```
+
+Group by course:
+
+```sql
+SELECT course, NULL AS type, count(*)
+FROM students
+GROUP BY course
+UNION ALL
+```
+
+Group by nothing:
+
+```sql
+SELECT NULL AS course, NULL AS type, count(*)
+FROM students;
+```
+
+`CUBE` and `ROLLUP` are syntactic sugar to easily produce commonly used grouping sets.
+
+The `ROLLUP` clause will produce all “sub-groups” of a grouping set, e.g., `ROLLUP (country, city, zip)` produces the grouping sets `(country, city, zip), (country, city), (country), ()`. This can be useful for producing different levels of detail of a group by clause. This produces `n+1` grouping sets where n is the amount of terms in the `ROLLUP` clause.
+
+`CUBE` produces grouping sets for all combinations of the inputs, e.g., `CUBE (country, city, zip)` will produce `(country, city, zip), (country, city), (country, zip), (city, zip), (country), (city), (zip), ()`. This produces `2^n` grouping sets.
+
+## Identifying Grouping Sets with `GROUPING_ID()`
+
+The super-aggregate rows generated by `GROUPING SETS`, `ROLLUP` and `CUBE` can often be identified by `NULL`-values returned for the respective column in the grouping. But if the columns used in the grouping can themselves contain actual `NULL`-values, then it can be challenging to distinguish whether the value in the resultset is a “real” `NULL`-value coming out of the data itself, or a `NULL`-value generated by the grouping construct. The `GROUPING_ID()` or `GROUPING()` function is designed to identify which groups generated the super-aggregate rows in the result.
+
+`GROUPING_ID()` is an aggregate function that takes the column expressions that make up the grouping(s). It returns a `BIGINT` value. The return value is `0` for the rows that are not super-aggregate rows. But for the super-aggregate rows, it returns an integer value that identifies the combination of expressions that make up the group for which the super-aggregate is generated. At this point, an example might help. Consider the following query:
+
+```sql
+WITH days AS (
+ SELECT
+ year("generate_series") AS y,
+ quarter("generate_series") AS q,
+ month("generate_series") AS m
+ FROM generate_series(DATE '2023-01-01', DATE '2023-12-31', INTERVAL 1 DAY)
+)
+SELECT y, q, m, GROUPING_ID(y, q, m) AS "grouping_id()"
+FROM days
+GROUP BY GROUPING SETS (
+ (y, q, m),
+ (y, q),
+ (y),
+ ()
+)
+ORDER BY y, q, m;
+```
+
+These are the results:
+
+| y | q | m | grouping_id() |
+|-----:|-----:|-----:|--------------:|
+| 2023 | 1 | 1 | 0 |
+| 2023 | 1 | 2 | 0 |
+| 2023 | 1 | 3 | 0 |
+| 2023 | 1 | NULL | 1 |
+| 2023 | 2 | 4 | 0 |
+| 2023 | 2 | 5 | 0 |
+| 2023 | 2 | 6 | 0 |
+| 2023 | 2 | NULL | 1 |
+| 2023 | 3 | 7 | 0 |
+| 2023 | 3 | 8 | 0 |
+| 2023 | 3 | 9 | 0 |
+| 2023 | 3 | NULL | 1 |
+| 2023 | 4 | 10 | 0 |
+| 2023 | 4 | 11 | 0 |
+| 2023 | 4 | 12 | 0 |
+| 2023 | 4 | NULL | 1 |
+| 2023 | NULL | NULL | 3 |
+| NULL | NULL | NULL | 7 |
+
+In this example, the lowest level of grouping is at the month level, defined by the grouping set `(y, q, m)`. Result rows corresponding to that level are simply aggregate rows and the `GROUPING_ID(y, q, m)` function returns `0` for those. The grouping set `(y, q)` results in super-aggregate rows over the month level, leaving a `NULL`-value for the `m` column, and for which `GROUPING_ID(y, q, m)` returns `1`. The grouping set `(y)` results in super-aggregate rows over the quarter level, leaving `NULL`-values for the `m` and `q` column, for which `GROUPING_ID(y, q, m)` returns `3`. Finally, the `()` grouping set results in one super-aggregate row for the entire resultset, leaving `NULL`-values for `y`, `q` and `m` and for which `GROUPING_ID(y, q, m)` returns `7`.
+
+To understand the relationship between the return value and the grouping set, you can think of `GROUPING_ID(y, q, m)` writing to a bitfield, where the first bit corresponds to the last expression passed to `GROUPING_ID()`, the second bit to the one-but-last expression passed to `GROUPING_ID()`, and so on. This may become clearer by casting `GROUPING_ID()` to `BIT`:
+
+```sql
+WITH days AS (
+ SELECT
+ year("generate_series") AS y,
+ quarter("generate_series") AS q,
+ month("generate_series") AS m
+ FROM generate_series(DATE '2023-01-01', DATE '2023-12-31', INTERVAL 1 DAY)
+)
+SELECT
+ y, q, m,
+ GROUPING_ID(y, q, m) AS "grouping_id(y, q, m)",
+ right(GROUPING_ID(y, q, m)::BIT::VARCHAR, 3) AS "y_q_m_bits"
+FROM days
+GROUP BY GROUPING SETS (
+ (y, q, m),
+ (y, q),
+ (y),
+ ()
+)
+ORDER BY y, q, m;
+```
+
+Which returns these results:
+
+| y | q | m | grouping_id(y, q, m) | y_q_m_bits |
+|-----:|-----:|-----:|---------------------:|------------|
+| 2023 | 1 | 1 | 0 | 000 |
+| 2023 | 1 | 2 | 0 | 000 |
+| 2023 | 1 | 3 | 0 | 000 |
+| 2023 | 1 | NULL | 1 | 001 |
+| 2023 | 2 | 4 | 0 | 000 |
+| 2023 | 2 | 5 | 0 | 000 |
+| 2023 | 2 | 6 | 0 | 000 |
+| 2023 | 2 | NULL | 1 | 001 |
+| 2023 | 3 | 7 | 0 | 000 |
+| 2023 | 3 | 8 | 0 | 000 |
+| 2023 | 3 | 9 | 0 | 000 |
+| 2023 | 3 | NULL | 1 | 001 |
+| 2023 | 4 | 10 | 0 | 000 |
+| 2023 | 4 | 11 | 0 | 000 |
+| 2023 | 4 | 12 | 0 | 000 |
+| 2023 | 4 | NULL | 1 | 001 |
+| 2023 | NULL | NULL | 3 | 011 |
+| NULL | NULL | NULL | 7 | 111 |
+
+Note that the number of expressions passed to `GROUPING_ID()`, or the order in which they are passed is independent from the actual group definitions appearing in the `GROUPING SETS`-clause (or the groups implied by `ROLLUP` and `CUBE`). As long as the expressions passed to `GROUPING_ID()` are expressions that appear some where in the `GROUPING SETS`-clause, `GROUPING_ID()` will set a bit corresponding to the position of the expression whenever that expression is rolled up to a super-aggregate.
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/having.md b/docs/archive/1.0/sql/query_syntax/having.md
new file mode 100644
index 00000000000..88f6e4afbd8
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/having.md
@@ -0,0 +1,31 @@
+---
+layout: docu
+railroad: query_syntax/groupby.js
+title: HAVING Clause
+---
+
+The `HAVING` clause can be used after the `GROUP BY` clause to provide filter criteria *after* the grouping has been completed. In terms of syntax the `HAVING` clause is identical to the `WHERE` clause, but while the `WHERE` clause occurs before the grouping, the `HAVING` clause occurs after the grouping.
+
+## Examples
+
+Count the number of entries in the `addresses` table that belong to each different `city`, filtering out cities with a count below 50:
+
+```sql
+SELECT city, count(*)
+FROM addresses
+GROUP BY city
+HAVING count(*) >= 50;
+```
+
+Compute the average income per city per `street_name`, filtering out cities with an average `income` bigger than twice the median `income`:
+
+```sql
+SELECT city, street_name, avg(income)
+FROM addresses
+GROUP BY city, street_name
+HAVING avg(income) > 2 * median(income);
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/limit.md b/docs/archive/1.0/sql/query_syntax/limit.md
new file mode 100644
index 00000000000..fd823e02821
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/limit.md
@@ -0,0 +1,42 @@
+---
+layout: docu
+railroad: query_syntax/orderby.js
+title: LIMIT and OFFSET Clauses
+---
+
+`LIMIT` is an output modifier. Logically it is applied at the very end of the query. The `LIMIT` clause restricts the amount of rows fetched. The `OFFSET` clause indicates at which position to start reading the values, i.e., the first `OFFSET` values are ignored.
+
+Note that while `LIMIT` can be used without an `ORDER BY` clause, the results might not be deterministic without the `ORDER BY` clause. This can still be useful, however, for example when you want to inspect a quick snapshot of the data.
+
+## Examples
+
+Select the first 5 rows from the addresses table:
+
+```sql
+SELECT *
+FROM addresses
+LIMIT 5;
+```
+
+Select the 5 rows from the addresses table, starting at position 5 (i.e., ignoring the first 5 rows):
+
+```sql
+SELECT *
+FROM addresses
+LIMIT 5
+OFFSET 5;
+```
+
+Select the top 5 cities with the highest population:
+
+```sql
+SELECT city, count(*) AS population
+FROM addresses
+GROUP BY city
+ORDER BY population DESC
+LIMIT 5;
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/orderby.md b/docs/archive/1.0/sql/query_syntax/orderby.md
new file mode 100644
index 00000000000..9ac47c41e0a
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/orderby.md
@@ -0,0 +1,134 @@
+---
+layout: docu
+railroad: query_syntax/orderby.js
+title: ORDER BY Clause
+---
+
+`ORDER BY` is an output modifier. Logically it is applied near the very end of the query (just prior to [`LIMIT`]({% link docs/archive/1.0/sql/query_syntax/limit.md %}) or [`OFFSET`]({% link docs/archive/1.0/sql/query_syntax/limit.md %}), if present).
+The `ORDER BY` clause sorts the rows on the sorting criteria in either ascending or descending order.
+In addition, every order clause can specify whether `NULL` values should be moved to the beginning or to the end.
+
+The `ORDER BY` clause may contain one or more expressions, separated by commas.
+An error will be thrown if no expressions are included, since the `ORDER BY` clause should be removed in that situation.
+The expressions may begin with either an arbitrary scalar expression (which could be a column name), a column position number (Ex: `1`. Note that it is 1-indexed), or the keyword `ALL`.
+Each expression can optionally be followed by an order modifier (`ASC` or `DESC`, default is `ASC`), and/or a `NULL` order modifier (`NULLS FIRST` or `NULLS LAST`, default is `NULLS LAST`).
+
+## `ORDER BY ALL`
+
+The `ALL` keyword indicates that the output should be sorted by every column in order from left to right.
+The direction of this sort may be modified using either `ORDER BY ALL ASC` or `ORDER BY ALL DESC` and/or `NULLS FIRST` or `NULLS LAST`.
+Note that `ALL` may not be used in combination with other expressions in the `ORDER BY` clause – it must be by itself.
+See examples below.
+
+## NULL Order Modifier
+
+By default if no modifiers are provided, DuckDB sorts `ASC NULLS LAST`, i.e., the values are sorted in ascending order and null values are placed last.
+This is identical to the default sort order of PostgreSQL. The default sort order can be changed with the following configuration options.
+
+> Using `ASC NULLS LAST` as the default sorting order was a breaking change in version 0.8.0. Prior to 0.8.0, DuckDB sorted using `ASC NULLS FIRST`.
+
+Change the default null sorting order to either `NULLS FIRST` and `NULLS LAST`:
+
+```sql
+SET default_null_order = 'NULLS FIRST';
+```
+
+Change the default sorting order to either `DESC` or `ASC`:
+
+```sql
+SET default_order = 'DESC';
+```
+
+## Collations
+
+Text is sorted using the binary comparison collation by default, which means values are sorted on their binary UTF-8 values.
+While this works well for ASCII text (e.g., for English language data), the sorting order can be incorrect for other languages.
+For this purpose, DuckDB provides collations.
+For more information on collations, see the [Collation page]({% link docs/archive/1.0/sql/expressions/collations.md %}).
+
+## Examples
+
+All examples use this example table:
+
+```sql
+CREATE OR REPLACE TABLE addresses AS
+ SELECT '123 Quack Blvd' AS address, 'DuckTown' AS city, '11111' AS zip
+ UNION ALL
+ SELECT '111 Duck Duck Goose Ln', 'DuckTown', '11111'
+ UNION ALL
+ SELECT '111 Duck Duck Goose Ln', 'Duck Town', '11111'
+ UNION ALL
+ SELECT '111 Duck Duck Goose Ln', 'Duck Town', '11111-0001';
+```
+
+Select the addresses, ordered by city name using the default null order and default order:
+
+```sql
+SELECT *
+FROM addresses
+ORDER BY city;
+```
+
+Select the addresses, ordered by city name in descending order with nulls at the end:
+
+```sql
+SELECT *
+FROM addresses
+ORDER BY city DESC NULLS LAST;
+```
+
+Order by city and then by zip code, both using the default orderings:
+
+```sql
+SELECT *
+FROM addresses
+ORDER BY city, zip;
+```
+
+Order by city using German collation rules:
+
+```sql
+SELECT *
+FROM addresses
+ORDER BY city COLLATE DE;
+```
+
+### `ORDER BY ALL` Examples
+
+Order from left to right (by address, then by city, then by zip) in ascending order:
+
+```sql
+SELECT *
+FROM addresses
+ORDER BY ALL;
+```
+
+
+
+| address | city | zip |
+|------------------------|-----------|------------|
+| 111 Duck Duck Goose Ln | Duck Town | 11111 |
+| 111 Duck Duck Goose Ln | Duck Town | 11111-0001 |
+| 111 Duck Duck Goose Ln | DuckTown | 11111 |
+| 123 Quack Blvd | DuckTown | 11111 |
+
+Order from left to right (by address, then by city, then by zip) in descending order:
+
+```sql
+SELECT *
+FROM addresses
+ORDER BY ALL DESC;
+```
+
+
+
+| address | city | zip |
+|------------------------|-----------|------------|
+| 123 Quack Blvd | DuckTown | 11111 |
+| 111 Duck Duck Goose Ln | DuckTown | 11111 |
+| 111 Duck Duck Goose Ln | Duck Town | 11111-0001 |
+| 111 Duck Duck Goose Ln | Duck Town | 11111 |
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/prepared_statements.md b/docs/archive/1.0/sql/query_syntax/prepared_statements.md
new file mode 100644
index 00000000000..eb5697945a7
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/prepared_statements.md
@@ -0,0 +1,100 @@
+---
+layout: docu
+title: Prepared Statements
+---
+
+DuckDB supports prepared statements where parameters are substituted when the query is executed.
+This can improve readability and is useful for preventing [SQL injections](https://en.wikipedia.org/wiki/SQL_injection).
+
+## Syntax
+
+There are three syntaxes for denoting parameters in prepared statements:
+auto-incremented (`?`),
+positional (`$1`),
+and named (`$param`).
+Note that not all clients support all of these syntaxes, e.g., the [JDBC client]({% link docs/archive/1.0/api/java.md %}) only supports auto-incremented parameters in prepared statements.
+
+### Example Data Set
+
+In the following, we introduce the three different syntaxes and illustrate them with examples using the following table.
+
+```sql
+CREATE TABLE person (name VARCHAR, age BIGINT);
+INSERT INTO person VALUES ('Alice', 37), ('Ana', 35), ('Bob', 41), ('Bea', 25);
+```
+
+In our example query, we'll look for people whose name starts with a `B` and are at least 40 years old.
+This will return a single row `<'Bob', 41>`.
+
+### Auto-Incremented Parameters: `?`
+
+DuckDB support using prepared statements with auto-incremented indexing,
+i.e., the position of the parameters in the query corresponds to their position in the execution statement.
+For example:
+
+```sql
+PREPARE query_person AS
+ SELECT *
+ FROM person
+ WHERE starts_with(name, ?)
+ AND age >= ?;
+```
+
+Using the CLI client, the statement is executed as follows.
+
+```sql
+EXECUTE query_person('B', 40);
+```
+
+### Positional Parameters: `$1`
+
+Prepared statements can use positional parameters, where parameters are denoted with an integer (`$1`, `$2`).
+For example:
+
+```sql
+PREPARE query_person AS
+ SELECT *
+ FROM person
+ WHERE starts_with(name, $2)
+ AND age >= $1;
+```
+
+Using the CLI client, the statement is executed as follows.
+Note that the first parameter corresponds to `$1`, the second to `$2`, and so on.
+
+```sql
+EXECUTE query_person(40, 'B');
+```
+
+### Named Parameters: `$parameter`
+
+DuckDB also supports names parameters where parameters are denoted with `$parameter_name`.
+For example:
+
+```sql
+PREPARE query_person AS
+ SELECT *
+ FROM person
+ WHERE starts_with(name, $name_start_letter)
+ AND age >= $minimum_age;
+```
+
+Using the CLI client, the statement is executed as follows.
+
+```sql
+EXECUTE query_person(name_start_letter := 'B', minimum_age := 40);
+```
+
+## Dropping Prepared Statements: `DEALLOCATE`
+
+To drop a prepared statement, use the `DEALLOCATE` statement:
+
+```sql
+DEALLOCATE query_person;
+```
+
+Alternatively, use:
+
+```sql
+DEALLOCATE PREPARE query_person;
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/qualify.md b/docs/archive/1.0/sql/query_syntax/qualify.md
new file mode 100644
index 00000000000..2ec527d08bc
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/qualify.md
@@ -0,0 +1,102 @@
+---
+blurb: The QUALIFY clause is used to filter the results of WINDOW functions.
+layout: docu
+railroad: query_syntax/qualify.js
+title: QUALIFY Clause
+---
+
+The `QUALIFY` clause is used to filter the results of [`WINDOW` functions]({% link docs/archive/1.0/sql/functions/window_functions.md %}). This filtering of results is similar to how a [`HAVING` clause]({% link docs/archive/1.0/sql/query_syntax/having.md %}) filters the results of aggregate functions applied based on the [`GROUP BY` clause]({% link docs/archive/1.0/sql/query_syntax/groupby.md %}).
+
+The `QUALIFY` clause avoids the need for a subquery or [`WITH` clause]({% link docs/archive/1.0/sql/query_syntax/with.md %}) to perform this filtering (much like `HAVING` avoids a subquery). An example using a `WITH` clause instead of `QUALIFY` is included below the `QUALIFY` examples.
+
+Note that this is filtering based on [`WINDOW` functions]({% link docs/archive/1.0/sql/functions/window_functions.md %}), not necessarily based on the [`WINDOW` clause]({% link docs/archive/1.0/sql/query_syntax/window.md %}). The `WINDOW` clause is optional and can be used to simplify the creation of multiple `WINDOW` function expressions.
+
+The position of where to specify a `QUALIFY` clause is following the [`WINDOW` clause]({% link docs/archive/1.0/sql/query_syntax/window.md %}) in a `SELECT` statement (`WINDOW` does not need to be specified), and before the [`ORDER BY`]({% link docs/archive/1.0/sql/query_syntax/orderby.md %}).
+
+## Examples
+
+Each of the following examples produce the same output, located below.
+
+Filter based on a window function defined in the `QUALIFY` clause:
+
+```sql
+SELECT
+ schema_name,
+ function_name,
+ -- In this example the function_rank column in the select clause is for reference
+ row_number() OVER (PARTITION BY schema_name ORDER BY function_name) AS function_rank
+FROM duckdb_functions()
+QUALIFY
+ row_number() OVER (PARTITION BY schema_name ORDER BY function_name) < 3;
+```
+
+Filter based on a window function defined in the `SELECT` clause:
+
+```sql
+SELECT
+ schema_name,
+ function_name,
+ row_number() OVER (PARTITION BY schema_name ORDER BY function_name) AS function_rank
+FROM duckdb_functions()
+QUALIFY
+ function_rank < 3;
+```
+
+Filter based on a window function defined in the `QUALIFY` clause, but using the `WINDOW` clause:
+
+```sql
+SELECT
+ schema_name,
+ function_name,
+ -- In this example the function_rank column in the select clause is for reference
+ row_number() OVER my_window AS function_rank
+FROM duckdb_functions()
+WINDOW
+ my_window AS (PARTITION BY schema_name ORDER BY function_name)
+QUALIFY
+ row_number() OVER my_window < 3;
+```
+
+Filter based on a window function defined in the `SELECT` clause, but using the `WINDOW` clause:
+
+```sql
+SELECT
+ schema_name,
+ function_name,
+ row_number() OVER my_window AS function_rank
+FROM duckdb_functions()
+WINDOW
+ my_window AS (PARTITION BY schema_name ORDER BY function_name)
+QUALIFY
+ function_rank < 3;
+```
+
+Equivalent query based on a `WITH` clause (without a `QUALIFY` clause):
+
+```sql
+WITH ranked_functions AS (
+ SELECT
+ schema_name,
+ function_name,
+ row_number() OVER (PARTITION BY schema_name ORDER BY function_name) AS function_rank
+ FROM duckdb_functions()
+)
+SELECT
+ *
+FROM ranked_functions
+WHERE
+ function_rank < 3;
+```
+
+
+
+| schema_name | function_name | function_rank |
+|:---|:---|:---|
+| main | !__postfix | 1 |
+| main | !~~ | 2 |
+| pg_catalog | col_description | 1 |
+| pg_catalog | format_pg_type | 2 |
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/sample.md b/docs/archive/1.0/sql/query_syntax/sample.md
new file mode 100644
index 00000000000..7f25c6cd319
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/sample.md
@@ -0,0 +1,37 @@
+---
+layout: docu
+railroad: query_syntax/sample.js
+title: SAMPLE Clause
+---
+
+The `SAMPLE` clause allows you to run the query on a sample from the base table. This can significantly speed up processing of queries, at the expense of accuracy in the result. Samples can also be used to quickly see a snapshot of the data when exploring a data set. The sample clause is applied right after anything in the `FROM` clause (i.e., after any joins, but before the `WHERE` clause or any aggregates). See the [`SAMPLE`]({% link docs/archive/1.0/sql/samples.md %}) page for more information.
+
+## Examples
+
+Select a sample of 1% of the addresses table using default (system) sampling:
+
+```sql
+SELECT *
+FROM addresses
+USING SAMPLE 1%;
+```
+
+Select a sample of 1% of the addresses table using bernoulli sampling:
+
+```sql
+SELECT *
+FROM addresses
+USING SAMPLE 1% (bernoulli);
+```
+
+Select a sample of 10 rows from the subquery:
+
+```sql
+SELECT *
+FROM (SELECT * FROM addresses)
+USING SAMPLE 10 ROWS;
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/select.md b/docs/archive/1.0/sql/query_syntax/select.md
new file mode 100644
index 00000000000..10f52126ccb
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/select.md
@@ -0,0 +1,173 @@
+---
+blurb: The SELECT clause specifies the list of columns that will be returned by the
+ query.
+layout: docu
+railroad: query_syntax/select.js
+title: SELECT Clause
+---
+
+The `SELECT` clause specifies the list of columns that will be returned by the query. While it appears first in the clause, *logically* the expressions here are executed only at the end. The `SELECT` clause can contain arbitrary expressions that transform the output, as well as aggregates and window functions.
+
+## Examples
+
+Select all columns from the table called `table_name`:
+
+```sql
+SELECT * FROM table_name;
+```
+
+Perform arithmetic on the columns in a table, and provide an alias:
+
+```sql
+SELECT col1 + col2 AS res, sqrt(col1) AS root FROM table_name;
+```
+
+Select all unique cities from the `addresses` table:
+
+```sql
+SELECT DISTINCT city FROM addresses;
+```
+
+Return the total number of rows in the `addresses` table:
+
+```sql
+SELECT count(*) FROM addresses;
+```
+
+Select all columns except the city column from the `addresses` table:
+
+```sql
+SELECT * EXCLUDE (city) FROM addresses;
+```
+
+Select all columns from the `addresses` table, but replace `city` with `lower(city)`:
+
+```sql
+SELECT * REPLACE (lower(city) AS city) FROM addresses;
+```
+
+Select all columns matching the given regular expression from the table:
+
+```sql
+SELECT COLUMNS('number\d+') FROM addresses;
+```
+
+Compute a function on all given columns of a table:
+
+```sql
+SELECT min(COLUMNS(*)) FROM addresses;
+```
+
+To select columns with spaces or special characters, use double quotes (`"`):
+
+```sql
+SELECT "Some Column Name" FROM tbl;
+```
+
+## Syntax
+
+
+
+## `SELECT` List
+
+The `SELECT` clause contains a list of expressions that specify the result of a query. The select list can refer to any columns in the `FROM` clause, and combine them using expressions. As the output of a SQL query is a table – every expression in the `SELECT` clause also has a name. The expressions can be explicitly named using the `AS` clause (e.g., `expr AS name`). If a name is not provided by the user the expressions are named automatically by the system.
+
+> Column names are case-insensitive. See the [Rules for Case Sensitivity]({% link docs/archive/1.0/sql/dialect/keywords_and_identifiers.md %}#rules-for-case-sensitivity) for more details.
+
+### Star Expressions
+
+Select all columns from the table called `table_name`:
+
+```sql
+SELECT *
+FROM table_name;
+```
+
+Select all columns matching the given regular expression from the table:
+
+```sql
+SELECT COLUMNS('number\d+')
+FROM addresses;
+```
+
+The [star expression]({% link docs/archive/1.0/sql/expressions/star.md %}) is a special expression that expands to *multiple expressions* based on the contents of the `FROM` clause. In the simplest case, `*` expands to **all** expressions in the `FROM` clause. Columns can also be selected using regular expressions or lambda functions. See the [star expression page]({% link docs/archive/1.0/sql/expressions/star.md %}) for more details.
+
+### `DISTINCT` Clause
+
+Select all unique cities from the addresses table:
+
+```sql
+SELECT DISTINCT city
+FROM addresses;
+```
+
+The `DISTINCT` clause can be used to return **only** the unique rows in the result – so that any duplicate rows are filtered out.
+
+> Queries starting with `SELECT DISTINCT` run deduplication, which is an expensive operation. Therefore, only use `DISTINCT` if necessary.
+
+### `DISTINCT ON` Clause
+
+Select only the highest population city for each country:
+
+```sql
+SELECT DISTINCT ON(country) city, population
+FROM cities
+ORDER BY population DESC;
+```
+
+The `DISTINCT ON` clause returns only one row per unique value in the set of expressions as defined in the `ON` clause. If an `ORDER BY` clause is present, the row that is returned is the first row that is encountered *as per the `ORDER BY`* criteria. If an `ORDER BY` clause is not present, the first row that is encountered is not defined and can be any row in the table.
+
+> When querying large data sets, using `DISTINCT` on all columns can be expensive. Therefore, consider using `DISTINCT ON` on a column (or a set of columns) which guaranetees a sufficient degree of uniqueness for your results. For example, using `DISTINCT ON` on the key column(s) of a table guarantees full uniqueness.
+
+### Aggregates
+
+Return the total number of rows in the addresses table:
+
+```sql
+SELECT count(*)
+FROM addresses;
+```
+
+Return the total number of rows in the addresses table grouped by city:
+
+```sql
+SELECT city, count(*)
+FROM addresses
+GROUP BY city;
+```
+
+[Aggregate functions]({% link docs/archive/1.0/sql/functions/aggregates.md %}) are special functions that *combine* multiple rows into a single value. When aggregate functions are present in the `SELECT` clause, the query is turned into an aggregate query. In an aggregate query, **all** expressions must either be part of an aggregate function, or part of a group (as specified by the [`GROUP BY clause`]({% link docs/archive/1.0/sql/query_syntax/groupby.md %})).
+
+### Window Functions
+
+Generate a `row_number` column containing incremental identifiers for each row:
+
+```sql
+SELECT row_number() OVER ()
+FROM sales;
+```
+
+Compute the difference between the current amount, and the previous amount, by order of time:
+
+```sql
+SELECT amount - lag(amount) OVER (ORDER BY time)
+FROM sales;
+```
+
+[Window functions]({% link docs/archive/1.0/sql/functions/window_functions.md %}) are special functions that allow the computation of values relative to *other rows* in a result. Window functions are marked by the `OVER` clause which contains the *window specification*. The window specification defines the frame or context in which the window function is computed. See the [window functions page]({% link docs/archive/1.0/sql/functions/window_functions.md %}) for more information.
+
+### `unnest` Function
+
+Unnest an array by one level:
+
+```sql
+SELECT unnest([1, 2, 3]);
+```
+
+Unnest a struct by one level:
+
+```sql
+SELECT unnest({'a': 42, 'b': 84});
+```
+
+The [`unnest`]({% link docs/archive/1.0/sql/query_syntax/unnest.md %}) function is a special function that can be used together with [arrays]({% link docs/archive/1.0/sql/data_types/array.md %}), [lists]({% link docs/archive/1.0/sql/data_types/list.md %}), or [structs]({% link docs/archive/1.0/sql/data_types/struct.md %}). The unnest function strips one level of nesting from the type. For example, `INTEGER[]` is transformed into `INTEGER`. `STRUCT(a INTEGER, b INTEGER)` is transformed into `a INTEGER, b INTEGER`. The unnest function can be used to transform nested types into regular scalar types, which makes them easier to operate on.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/setops.md b/docs/archive/1.0/sql/query_syntax/setops.md
new file mode 100644
index 00000000000..8856b0c3f1a
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/setops.md
@@ -0,0 +1,158 @@
+---
+layout: docu
+railroad: query_syntax/setops.js
+title: Set Operations
+---
+
+Set operations allow queries to be combined according to [set operation semantics](https://en.wikipedia.org/wiki/Set_(mathematics)#Basic_operations). Set operations refer to the [`UNION [ALL]`](#union), [`INTERSECT [ALL]`](#intersect) and [`EXCEPT [ALL]`](#except) clauses. The vanilla variants use set semantics, i.e., they eliminate duplicates, while the variants with `ALL` use bag semantics.
+
+Traditional set operations unify queries **by column position**, and require the to-be-combined queries to have the same number of input columns. If the columns are not of the same type, casts may be added. The result will use the column names from the first query.
+
+DuckDB also supports [`UNION [ALL] BY NAME`](#union-all-by-name), which joins columns by name instead of by position. `UNION BY NAME` does not require the inputs to have the same number of columns. `NULL` values will be added in case of missing columns.
+
+## `UNION`
+
+The `UNION` clause can be used to combine rows from multiple queries. The queries are required to return the same number of columns. [Implicit casting](https://duckdb.org/docs/sql/data_types/typecasting#implicit-casting) to one of the returned types is performed to combine columns of different types where necessary. If this is not possible, the `UNION` clause throws an error.
+
+### Vanilla `UNION` (Set Semantics)
+
+The vanilla `UNION` clause follows set semantics, therefore it performs duplicate elimination, i.e., only unique rows will be included in the result.
+
+```sql
+SELECT * FROM range(2) t1(x)
+UNION
+SELECT * FROM range(3) t2(x);
+```
+
+| x |
+|--:|
+| 2 |
+| 1 |
+| 0 |
+
+### `UNION ALL` (Bag Semantics)
+
+`UNION ALL` returns all rows of both queries following bag semantics, i.e., *without* duplicate elimination.
+
+```sql
+SELECT * FROM range(2) t1(x)
+UNION ALL
+SELECT * FROM range(3) t2(x);
+```
+
+| x |
+|--:|
+| 0 |
+| 1 |
+| 0 |
+| 1 |
+| 2 |
+
+### `UNION [ALL] BY NAME`
+
+The `UNION [ALL] BY NAME` clause can be used to combine rows from different tables by name, instead of by position. `UNION BY NAME` does not require both queries to have the same number of columns. Any columns that are only found in one of the queries are filled with `NULL` values for the other query.
+
+Take the following tables for example:
+
+```sql
+CREATE TABLE capitals (city VARCHAR, country VARCHAR);
+INSERT INTO capitals VALUES
+ ('Amsterdam', 'NL'),
+ ('Berlin', 'Germany');
+CREATE TABLE weather (city VARCHAR, degrees INTEGER, date DATE);
+INSERT INTO weather VALUES
+ ('Amsterdam', 10, '2022-10-14'),
+ ('Seattle', 8, '2022-10-12');
+```
+
+```sql
+SELECT * FROM capitals
+UNION BY NAME
+SELECT * FROM weather;
+```
+
+| city | country | degrees | date |
+|-----------|---------|--------:|------------|
+| Seattle | NULL | 8 | 2022-10-12 |
+| Amsterdam | NL | NULL | NULL |
+| Berlin | Germany | NULL | NULL |
+| Amsterdam | NULL | 10 | 2022-10-14 |
+
+`UNION BY NAME` follows set semantics (therefore it performs duplicate elimination), whereas `UNION ALL BY NAME` follows bag semantics.
+
+## `INTERSECT`
+
+The `INTERSECT` clause can be used to select all rows that occur in the result of **both** queries.
+
+### Vanilla `INTERSECT` (Set Semantics)
+
+Vanilla `INTERSECT` performs duplicate elimination, so only unique rows are returned.
+
+```sql
+SELECT * FROM range(2) t1(x)
+INTERSECT
+SELECT * FROM range(6) t2(x);
+```
+
+| x |
+|--:|
+| 0 |
+| 1 |
+
+### `INTERSECT ALL` (Bag Semantics)
+
+`INTERSECT ALL` follows bag semantics, so duplicates are returned.
+
+```sql
+SELECT unnest([5, 5, 6, 6, 6, 6, 7, 8]) AS x
+INTERSECT ALL
+SELECT unnest([5, 6, 6, 7, 7, 9]);
+```
+
+| x |
+|--:|
+| 5 |
+| 6 |
+| 6 |
+| 7 |
+
+## `EXCEPT`
+
+The `EXCEPT` clause can be used to select all rows that **only** occur in the left query.
+
+### Vanilla `EXCEPT` (Set Semantics)
+
+Vanilla `EXCEPT` follows set semantics, therefore, it performs duplicate elimination, so only unique rows are returned.
+
+```sql
+SELECT * FROM range(5) t1(x)
+EXCEPT
+SELECT * FROM range(2) t2(x);
+```
+
+| x |
+|--:|
+| 2 |
+| 3 |
+| 4 |
+
+### `EXCEPT ALL` (Bag Semantics)
+
+`EXCEPT ALL` uses bag semantics:
+
+```sql
+SELECT unnest([5, 5, 6, 6, 6, 6, 7, 8]) AS x
+EXCEPT ALL
+SELECT unnest([5, 6, 6, 7, 7, 9]);
+```
+
+| x |
+|--:|
+| 5 |
+| 8 |
+| 6 |
+| 6 |
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/unnest.md b/docs/archive/1.0/sql/query_syntax/unnest.md
new file mode 100644
index 00000000000..856cf309f0f
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/unnest.md
@@ -0,0 +1,167 @@
+---
+layout: docu
+title: Unnesting
+---
+
+## Examples
+
+Unnest a list, generating 3 rows (1, 2, 3):
+
+```sql
+SELECT unnest([1, 2, 3]);
+```
+
+Unnesting a struct, generating two columns (a, b):
+
+```sql
+SELECT unnest({'a': 42, 'b': 84});
+```
+
+Recursive unnest of a list of structs:
+
+```sql
+SELECT unnest([{'a': 42, 'b': 84}, {'a': 100, 'b': NULL}], recursive := true);
+```
+
+Limit depth of recursive unnest using `max_depth`:
+
+```sql
+SELECT unnest([[[1, 2], [3, 4]], [[5, 6], [7, 8, 9], []], [[10, 11]]], max_depth := 2);
+```
+
+The `unnest` special function is used to unnest lists or structs by one level. The function can be used as a regular scalar function, but only in the `SELECT` clause. Invoking `unnest` with the `recursive` parameter will unnest lists and structs of multiple levels. The depth of unnesting can be limited using the `max_depth` parameter (which assumes `recursive` unnesting by default).
+
+### Unnesting Lists
+
+Unnest a list, generating 3 rows (1, 2, 3):
+
+```sql
+SELECT unnest([1, 2, 3]);
+```
+
+Unnest a scalar list, generating 3 rows ((1, 10), (2, 11), (3, NULL)):
+
+```sql
+SELECT unnest([1, 2, 3]), unnest([10, 11]);
+```
+
+Unnest a scalar list, generating 3 rows ((1, 10), (2, 10), (3, 10)):
+
+```sql
+SELECT unnest([1, 2, 3]), 10;
+```
+
+Unnest a list column generated from a subquery:
+
+```sql
+SELECT unnest(l) + 10 FROM (VALUES ([1, 2, 3]), ([4, 5])) tbl(l);
+```
+
+Empty result:
+
+```sql
+SELECT unnest([]);
+```
+
+Empty result:
+
+```sql
+SELECT unnest(NULL);
+```
+
+Using `unnest` on a list will emit one tuple per entry in the list. When `unnest` is combined with regular scalar expressions, those expressions are repeated for every entry in the list. When multiple lists are unnested in the same `SELECT` clause, the lists are unnested side-by-side. If one list is longer than the other, the shorter list will be padded with `NULL` values.
+
+An empty list and a `NULL` list will both unnest to zero elements.
+
+### Unnesting Structs
+
+Unnesting a struct, generating two columns (a, b):
+
+```sql
+SELECT unnest({'a': 42, 'b': 84});
+```
+
+Unnesting a struct, generating two columns (a, b):
+
+```sql
+SELECT unnest({'a': 42, 'b': {'x': 84}});
+```
+
+`unnest` on a struct will emit one column per entry in the struct.
+
+### Recursive Unnest
+
+Unnesting a list of lists recursively, generating 5 rows (1, 2, 3, 4, 5):
+
+```sql
+SELECT unnest([[1, 2, 3], [4, 5]], recursive := true);
+```
+
+Unnesting a list of structs recursively, generating two rows of two columns (a, b):
+
+```sql
+SELECT unnest([{'a': 42, 'b': 84}, {'a': 100, 'b': NULL}], recursive := true);
+```
+
+Unnesting a struct, generating two columns (a, b):
+
+```sql
+SELECT unnest({'a': [1, 2, 3], 'b': 88}, recursive := true);
+```
+
+Calling `unnest` with the `recursive` setting will fully unnest lists, followed by fully unnesting structs. This can be useful to fully flatten columns that contain lists within lists, or lists of structs. Note that lists *within* structs are not unnested.
+
+### Setting the Maximum Depth of Unnesting
+
+The `max_depth` parameter allows limiting the maximum depth of recursive unnesting (which is assumed by default and does not have to be specified separately).
+For example, unnestig to `max_depth` of 2 yields the following:
+
+```sql
+SELECT unnest([[[1, 2], [3, 4]], [[5, 6], [7, 8, 9], []], [[10, 11]]], max_depth := 2) AS x;
+```
+
+| x |
+|-----------|
+| [1, 2] |
+| [3, 4] |
+| [5, 6] |
+| [7, 8, 9] |
+| [] |
+| [10, 11] |
+
+Meanwhile, unnesting to `max_depth` of 3 results in:
+
+```sql
+SELECT unnest([[[1, 2], [3, 4]], [[5, 6], [7, 8, 9], []], [[10, 11]]], max_depth := 3) AS x;
+```
+
+| x |
+|---:|
+| 1 |
+| 2 |
+| 3 |
+| 4 |
+| 5 |
+| 6 |
+| 7 |
+| 8 |
+| 9 |
+| 10 |
+| 11 |
+
+### Keeping Track of List Entry Positions
+
+To keep track of each entry's position within the original list, `unnest` may be combined with [`generate_subscripts`]({% link docs/archive/1.0/sql/functions/nested.md %}#generate_subscripts):
+
+```sql
+SELECT unnest(l) as x, generate_subscripts(l, 1) AS index
+FROM (VALUES ([1, 2, 3]), ([4, 5])) tbl(l);
+```
+
+| x | index |
+|--:|------:|
+| 1 | 1 |
+| 2 | 2 |
+| 3 | 3 |
+| 4 | 1 |
+| 5 | 2 |
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/values.md b/docs/archive/1.0/sql/query_syntax/values.md
new file mode 100644
index 00000000000..4789b0e7fa3
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/values.md
@@ -0,0 +1,41 @@
+---
+layout: docu
+railroad: query_syntax/values.js
+title: VALUES Clause
+---
+
+The `VALUES` clause is used to specify a fixed number of rows. The `VALUES` clause can be used as a stand-alone statement, as part of the `FROM` clause, or as input to an `INSERT INTO` statement.
+
+## Examples
+
+Generate two rows and directly return them:
+
+```sql
+VALUES ('Amsterdam', 1), ('London', 2);
+```
+
+Generate two rows as part of a `FROM` clause, and rename the columns:
+
+```sql
+SELECT *
+FROM (VALUES ('Amsterdam', 1), ('London', 2)) cities(name, id);
+```
+
+Generate two rows and insert them into a table:
+
+```sql
+INSERT INTO cities
+VALUES ('Amsterdam', 1), ('London', 2);
+```
+
+Create a table directly from a `VALUES` clause:
+
+```sql
+CREATE TABLE cities AS
+ SELECT *
+ FROM (VALUES ('Amsterdam', 1), ('London', 2)) cities(name, id);
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/where.md b/docs/archive/1.0/sql/query_syntax/where.md
new file mode 100644
index 00000000000..75bf4a9fc6c
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/where.md
@@ -0,0 +1,37 @@
+---
+layout: docu
+railroad: query_syntax/where.js
+title: WHERE Clause
+---
+
+The `WHERE` clause specifies any filters to apply to the data. This allows you to select only a subset of the data in which you are interested. Logically the `WHERE` clause is applied immediately after the `FROM` clause.
+
+## Examples
+
+Select all rows that where the `id` is equal to 3:
+
+```sql
+SELECT *
+FROM table_name
+WHERE id = 3;
+```
+
+Select all rows that match the given case-insensitive `LIKE` expression:
+
+```sql
+SELECT *
+FROM table_name
+WHERE name ILIKE '%mark%';
+```
+
+Select all rows that match the given composite expression:
+
+```sql
+SELECT *
+FROM table_name
+WHERE id = 3 OR id = 7;
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/window.md b/docs/archive/1.0/sql/query_syntax/window.md
new file mode 100644
index 00000000000..dac31a5f750
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/window.md
@@ -0,0 +1,11 @@
+---
+layout: docu
+railroad: query_syntax/window.js
+title: WINDOW Clause
+---
+
+The `WINDOW` clause allows you to specify named windows that can be used within [window functions]({% link docs/archive/1.0/sql/functions/window_functions.md %}). These are useful when you have multiple window functions, as they allow you to avoid repeating the same window clause.
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/query_syntax/with.md b/docs/archive/1.0/sql/query_syntax/with.md
new file mode 100644
index 00000000000..784c589c0e0
--- /dev/null
+++ b/docs/archive/1.0/sql/query_syntax/with.md
@@ -0,0 +1,302 @@
+---
+layout: docu
+railroad: query_syntax/with.js
+title: WITH Clause
+---
+
+The `WITH` clause allows you to specify common table expressions (CTEs). Regular (non-recursive) common-table-expressions are essentially views that are limited in scope to a particular query. CTEs can reference each-other and can be nested. [Recursive CTEs](#recursive-ctes) can reference themselves.
+
+## Basic CTE Examples
+
+Create a CTE called “cte” and use it in the main query:
+
+```sql
+WITH cte AS (SELECT 42 AS x)
+SELECT * FROM cte;
+```
+
+| x |
+|---:|
+| 42 |
+
+Create two CTEs, where the second CTE references the first CTE:
+
+```sql
+WITH
+ cte AS (SELECT 42 AS i),
+ cte2 AS (SELECT i * 100 AS x FROM cte)
+SELECT * FROM cte2;
+```
+
+| x |
+|-----:|
+| 4200 |
+
+## Materialized CTEs
+
+By default, CTEs are inlined into the main query. Inlining can result in duplicate work, because the definition is copied for each reference. Take this query for example:
+
+```sql
+WITH t(x) AS (⟨Q_t⟩)
+SELECT *
+FROM t AS t1,
+ t AS t2,
+ t AS t3;
+```
+
+Inlining duplicates the definition of `t` for each reference which results in the following query:
+
+```sql
+SELECT *
+FROM (⟨Q_t⟩) AS t1(x),
+ (⟨Q_t⟩) AS t2(x),
+ (⟨Q_t⟩) AS t3(x);
+```
+
+If `⟨Q_t⟩` is expensive, materializing it with the `MATERIALIZED` keyword can improve performance. In this case, `⟨Q_t⟩` is evaluated only once.
+
+```sql
+WITH t(x) AS MATERIALIZED (⟨Q_t⟩)
+SELECT *
+FROM t AS t1,
+ t AS t2,
+ t AS t3;
+```
+
+## Recursive CTEs
+
+`WITH RECURSIVE` allows the definition of CTEs which can refer to themselves. Note that the query must be formulated in a way that ensures termination, otherwise, it may run into an infinite loop.
+
+### Example: Fibonacci Sequence
+
+`WITH RECURSIVE` can be used to make recursive calculations. For example, here is how `WITH RECURSIVE` could be used to calculate the first ten Fibonacci numbers:
+
+```sql
+WITH RECURSIVE FibonacciNumbers (RecursionDepth, FibonacciNumber, NextNumber) AS (
+ -- Base case
+ SELECT
+ 0 AS RecursionDepth,
+ 0 AS FibonacciNumber,
+ 1 AS NextNumber
+ UNION ALL
+ -- Recursive step
+ SELECT
+ fib.RecursionDepth + 1 AS RecursionDepth,
+ fib.NextNumber AS FibonacciNumber,
+ fib.FibonacciNumber + fib.NextNumber AS NextNumber
+ FROM
+ FibonacciNumbers fib
+ WHERE
+ fib.RecursionDepth + 1 < 10
+ )
+SELECT
+ fn.RecursionDepth AS FibonacciNumberIndex,
+ fn.FibonacciNumber
+FROM
+ FibonacciNumbers fn;
+```
+
+| FibonacciNumberIndex | FibonacciNumber |
+|---------------------:|----------------:|
+| 0 | 0 |
+| 1 | 1 |
+| 2 | 1 |
+| 3 | 2 |
+| 4 | 3 |
+| 5 | 5 |
+| 6 | 8 |
+| 7 | 13 |
+| 8 | 21 |
+| 9 | 34 |
+
+### Example: Tree Traversal
+
+`WITH RECURSIVE` can be used to traverse trees. For example, take a hierarchy of tags:
+
+
+
+```sql
+CREATE TABLE tag (id INTEGER, name VARCHAR, subclassof INTEGER);
+INSERT INTO tag VALUES
+ (1, 'U2', 5),
+ (2, 'Blur', 5),
+ (3, 'Oasis', 5),
+ (4, '2Pac', 6),
+ (5, 'Rock', 7),
+ (6, 'Rap', 7),
+ (7, 'Music', 9),
+ (8, 'Movies', 9),
+ (9, 'Art', NULL);
+```
+
+The following query returns the path from the node `Oasis` to the root of the tree (`Art`).
+
+```sql
+WITH RECURSIVE tag_hierarchy(id, source, path) AS (
+ SELECT id, name, [name] AS path
+ FROM tag
+ WHERE subclassof IS NULL
+ UNION ALL
+ SELECT tag.id, tag.name, list_prepend(tag.name, tag_hierarchy.path)
+ FROM tag, tag_hierarchy
+ WHERE tag.subclassof = tag_hierarchy.id
+ )
+SELECT path
+FROM tag_hierarchy
+WHERE source = 'Oasis';
+```
+
+| path |
+|---------------------------|
+| [Oasis, Rock, Music, Art] |
+
+### Graph Traversal
+
+The `WITH RECURSIVE` clause can be used to express graph traversal on arbitrary graphs. However, if the graph has cycles, the query must perform cycle detection to prevent infinite loops.
+One way to achieve this is to store the path of a traversal in a [list]({% link docs/archive/1.0/sql/data_types/list.md %}) and, before extending the path with a new edge, check whether its endpoint has been visited before (see the example later).
+
+Take the following directed graph from the [LDBC Graphalytics benchmark](https://arxiv.org/pdf/2011.15028.pdf):
+
+
+
+```sql
+CREATE TABLE edge (node1id INTEGER, node2id INTEGER);
+INSERT INTO edge VALUES
+ (1, 3), (1, 5), (2, 4), (2, 5), (2, 10), (3, 1),
+ (3, 5), (3, 8), (3, 10), (5, 3), (5, 4), (5, 8),
+ (6, 3), (6, 4), (7, 4), (8, 1), (9, 4);
+```
+
+Note that the graph contains directed cycles, e.g., between nodes 1, 2, and 5.
+
+#### Enumerate All Paths from a Node
+
+The following query returns **all paths** starting in node 1:
+
+```sql
+WITH RECURSIVE paths(startNode, endNode, path) AS (
+ SELECT -- Define the path as the first edge of the traversal
+ node1id AS startNode,
+ node2id AS endNode,
+ [node1id, node2id] AS path
+ FROM edge
+ WHERE startNode = 1
+ UNION ALL
+ SELECT -- Concatenate new edge to the path
+ paths.startNode AS startNode,
+ node2id AS endNode,
+ array_append(path, node2id) AS path
+ FROM paths
+ JOIN edge ON paths.endNode = node1id
+ -- Prevent adding a repeated node to the path.
+ -- This ensures that no cycles occur.
+ WHERE list_position(paths.path, node2id) = 0
+ )
+SELECT startNode, endNode, path
+FROM paths
+ORDER BY length(path), path;
+```
+
+| startNode | endNode | path |
+|----------:|--------:|---------------|
+| 1 | 3 | [1, 3] |
+| 1 | 5 | [1, 5] |
+| 1 | 5 | [1, 3, 5] |
+| 1 | 8 | [1, 3, 8] |
+| 1 | 10 | [1, 3, 10] |
+| 1 | 3 | [1, 5, 3] |
+| 1 | 4 | [1, 5, 4] |
+| 1 | 8 | [1, 5, 8] |
+| 1 | 4 | [1, 3, 5, 4] |
+| 1 | 8 | [1, 3, 5, 8] |
+| 1 | 8 | [1, 5, 3, 8] |
+| 1 | 10 | [1, 5, 3, 10] |
+
+Note that the result of this query is not restricted to shortest paths, e.g., for node 5, the results include paths `[1, 5]` and `[1, 3, 5]`.
+
+#### Enumerate Unweighted Shortest Paths from a Node
+
+In most cases, enumerating all paths is not practical or feasible. Instead, only the **(unweighted) shortest paths** are of interest. To find these, the second half of the `WITH RECURSIVE` query should be adjusted such that it only includes a node if it has not yet been visited. This is implemented by using a subquery that checks if any of the previous paths includes the node:
+
+```sql
+WITH RECURSIVE paths(startNode, endNode, path) AS (
+ SELECT -- Define the path as the first edge of the traversal
+ node1id AS startNode,
+ node2id AS endNode,
+ [node1id, node2id] AS path
+ FROM edge
+ WHERE startNode = 1
+ UNION ALL
+ SELECT -- Concatenate new edge to the path
+ paths.startNode AS startNode,
+ node2id AS endNode,
+ array_append(path, node2id) AS path
+ FROM paths
+ JOIN edge ON paths.endNode = node1id
+ -- Prevent adding a node that was visited previously by any path.
+ -- This ensures that (1) no cycles occur and (2) only nodes that
+ -- were not visited by previous (shorter) paths are added to a path.
+ WHERE NOT EXISTS (
+ FROM paths previous_paths
+ WHERE list_contains(previous_paths.path, node2id)
+ )
+ )
+SELECT startNode, endNode, path
+FROM paths
+ORDER BY length(path), path;
+```
+
+| startNode | endNode | path |
+|----------:|--------:|------------|
+| 1 | 3 | [1, 3] |
+| 1 | 5 | [1, 5] |
+| 1 | 8 | [1, 3, 8] |
+| 1 | 10 | [1, 3, 10] |
+| 1 | 4 | [1, 5, 4] |
+| 1 | 8 | [1, 5, 8] |
+
+#### Enumerate Unweighted Shortest Paths between Two Nodes
+
+`WITH RECURSIVE` can also be used to find **all (unweighted) shortest paths between two nodes**. To ensure that the recursive query is stopped as soon as we reach the end node, we use a [window function]({% link docs/archive/1.0/sql/functions/window_functions.md %}) which checks whether the end node is among the newly added nodes.
+
+The following query returns all unweighted shortest paths between nodes 1 (start node) and 8 (end node):
+
+```sql
+WITH RECURSIVE paths(startNode, endNode, path, endReached) AS (
+ SELECT -- Define the path as the first edge of the traversal
+ node1id AS startNode,
+ node2id AS endNode,
+ [node1id, node2id] AS path,
+ (node2id = 8) AS endReached
+ FROM edge
+ WHERE startNode = 1
+ UNION ALL
+ SELECT -- Concatenate new edge to the path
+ paths.startNode AS startNode,
+ node2id AS endNode,
+ array_append(path, node2id) AS path,
+ max(CASE WHEN node2id = 8 THEN 1 ELSE 0 END)
+ OVER (ROWS BETWEEN UNBOUNDED PRECEDING
+ AND UNBOUNDED FOLLOWING) AS endReached
+ FROM paths
+ JOIN edge ON paths.endNode = node1id
+ WHERE NOT EXISTS (
+ FROM paths previous_paths
+ WHERE list_contains(previous_paths.path, node2id)
+ )
+ AND paths.endReached = 0
+)
+SELECT startNode, endNode, path
+FROM paths
+WHERE endNode = 8
+ORDER BY length(path), path;
+```
+
+| startNode | endNode | path |
+|----------:|--------:|-----------|
+| 1 | 8 | [1, 3, 8] |
+| 1 | 8 | [1, 5, 8] |
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/samples.md b/docs/archive/1.0/sql/samples.md
new file mode 100644
index 00000000000..5f8286e0045
--- /dev/null
+++ b/docs/archive/1.0/sql/samples.md
@@ -0,0 +1,131 @@
+---
+layout: docu
+railroad: statements/samples.js
+title: Samples
+---
+
+Samples are used to randomly select a subset of a dataset.
+
+### Examples
+
+Select a sample of 5 rows from `tbl` using reservoir sampling:
+
+```sql
+SELECT *
+FROM tbl
+USING SAMPLE 5;
+```
+
+Select a sample of 10% of the table using system sampling (cluster sampling):
+
+```sql
+SELECT *
+FROM tbl
+USING SAMPLE 10%;
+```
+
+Select a sample of 10% of the table using bernoulli sampling:
+
+```sql
+SELECT *
+FROM tbl
+USING SAMPLE 10 PERCENT (bernoulli);
+```
+
+Select a sample of 50 rows of the table using reservoir sampling with a fixed seed (100):
+
+```sql
+SELECT *
+FROM tbl
+USING SAMPLE reservoir(50 ROWS)
+REPEATABLE (100);
+```
+
+Select a sample of 20% of the table using system sampling with a fixed seed (377):
+
+```sql
+SELECT *
+FROM tbl
+USING SAMPLE 20% (system, 377);
+```
+
+Select a sample of 20% of `tbl` **before** the join with `tbl2`:
+
+```sql
+SELECT *
+FROM tbl TABLESAMPLE reservoir(20%), tbl2
+WHERE tbl.i = tbl2.i;
+```
+
+Select a sample of 20% of `tbl` **after** the join with `tbl2`:
+
+```sql
+SELECT *
+FROM tbl, tbl2
+WHERE tbl.i = tbl2.i
+USING SAMPLE reservoir(20%);
+```
+
+### Syntax
+
+
+
+Samples allow you to randomly extract a subset of a dataset. Samples are useful for exploring a dataset faster, as often you might not be interested in the exact answers to queries, but only in rough indications of what the data looks like and what is in the data. Samples allow you to get approximate answers to queries faster, as they reduce the amount of data that needs to pass through the query engine.
+
+DuckDB supports three different types of sampling methods: `reservoir`, `bernoulli` and `system`. By default, DuckDB uses `reservoir` sampling when an exact number of rows is sampled, and `system` sampling when a percentage is specified. The sampling methods are described in detail below.
+
+Samples require a *sample size*, which is an indication of how many elements will be sampled from the total population. Samples can either be given as a percentage (`10%`) or as a fixed number of rows (`10 rows`). All three sampling methods support sampling over a percentage, but **only** reservoir sampling supports sampling a fixed number of rows.
+
+Samples are probablistic, that is to say, samples can be different between runs *unless* the seed is specifically specified. Specifying the seed *only* guarantees that the sample is the same if multi-threading is not enabled (i.e., `SET threads = 1`). In the case of multiple threads running over a sample, samples are not necessarily consistent even with a fixed seed.
+
+### `reservoir`
+
+Reservoir sampling is a stream sampling technique that selects a random sample by keeping a *reservoir* of size equal to the sample size, and randomly replacing elements as more elements come in. Reservoir sampling allows us to specify *exactly* how many elements we want in the resulting sample (by selecting the size of the reservoir). As a result, reservoir sampling *always* outputs the same amount of elements, unlike system and bernoulli sampling.
+
+Reservoir sampling is only recommended for small sample sizes, and is not recommended for use with percentages. That is because reservoir sampling needs to materialize the entire sample and randomly replace tuples within the materialized sample. The larger the sample size, the higher the performance hit incurred by this process.
+
+Reservoir sampling also incurs an additional performance penalty when multi-processing is used, since the reservoir is to be shared amongst the different threads to ensure unbiased sampling. This is not a big problem when the reservoir is very small, but becomes costly when the sample is large.
+
+> Bestpractice Avoid using reservoir sampling with large sample sizes if possible.
+> Reservoir sampling requires the entire sample to be materialized in memory.
+
+### `bernoulli`
+
+Bernoulli sampling can only be used when a sampling percentage is specified. It is rather straightforward: every tuple in the underlying table is included with a chance equal to the specified percentage. As a result, bernoulli sampling can return a different number of tuples even if the same percentage is specified. The amount of rows will generally be more or less equal to the specified percentage of the table, but there will be some variance.
+
+Because bernoulli sampling is completely independent (there is no shared state), there is no penalty for using bernoulli sampling together with multiple threads.
+
+### `system`
+
+System sampling is a variant of bernoulli sampling with one crucial difference: every *vector* is included with a chance equal to the sampling percentage. This is a form of cluster sampling. System sampling is more efficient than bernoulli sampling, as no per-tuple selections have to be performed. There is almost no extra overhead for using system sampling, whereas bernoulli sampling can add additional cost as it has to perform random number generation for every single tuple.
+
+System sampling is not suitable for smaller data sets as the granularity of the sampling is on the order of ~1000 tuples. That means that if system sampling is used for small data sets (e.g., 100 rows) either all the data will be filtered out, or all the data will be included.
+
+## Table Samples
+
+The `TABLESAMPLE` and `USING SAMPLE` clauses are identical in terms of syntax and effect, with one important difference: tablesamples sample directly from the table for which they are specified, whereas the sample clause samples after the entire from clause has been resolved. This is relevant when there are joins present in the query plan.
+
+The `TABLESAMPLE` clause is essentially equivalent to creating a subquery with the `USING SAMPLE` clause, i.e., the following two queries are identical:
+
+Sample 20% of `tbl` **before** the join:
+
+```sql
+SELECT * FROM tbl TABLESAMPLE reservoir(20%), tbl2 WHERE tbl.i = tbl2.i;
+```
+
+Sample 20% of `tbl` **before** the join:
+
+```sql
+SELECT *
+FROM (SELECT * FROM tbl USING SAMPLE reservoir(20%)) tbl, tbl2
+WHERE tbl.i = tbl2.i;
+```
+
+Sample 20% **after** the join (i.e., sample 20% of the join result):
+
+```sql
+SELECT *
+FROM tbl, tbl2
+WHERE tbl.i = tbl2.i
+USING SAMPLE reservoir(20%);
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/alter_table.md b/docs/archive/1.0/sql/statements/alter_table.md
new file mode 100644
index 00000000000..0e22a19d299
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/alter_table.md
@@ -0,0 +1,166 @@
+---
+layout: docu
+railroad: statements/alter.js
+title: ALTER TABLE Statement
+---
+
+The `ALTER TABLE` statement changes the schema of an existing table in the catalog.
+
+## Examples
+
+Add a new column with name `k` to the table `integers`, it will be filled with the default value NULL:
+
+```sql
+ALTER TABLE integers ADD COLUMN k INTEGER;
+```
+
+Add a new column with name `l` to the table integers, it will be filled with the default value 10:
+
+```sql
+ALTER TABLE integers ADD COLUMN l INTEGER DEFAULT 10;
+```
+
+Drop the column `k` from the table integers:
+
+```sql
+ALTER TABLE integers DROP k;
+```
+
+Change the type of the column `i` to the type `VARCHAR` using a standard cast:
+
+```sql
+ALTER TABLE integers ALTER i TYPE VARCHAR;
+```
+
+Change the type of the column `i` to the type `VARCHAR`, using the specified expression to convert the data for each row:
+
+```sql
+ALTER TABLE integers ALTER i SET DATA TYPE VARCHAR USING concat(i, '_', j);
+```
+
+Set the default value of a column:
+
+```sql
+ALTER TABLE integers ALTER COLUMN i SET DEFAULT 10;
+```
+
+Drop the default value of a column:
+
+```sql
+ALTER TABLE integers ALTER COLUMN i DROP DEFAULT;
+```
+
+Make a column not nullable:
+
+```sql
+ALTER TABLE t ALTER COLUMN x SET NOT NULL;
+```
+
+Drop the not null constraint:
+
+```sql
+ALTER TABLE t ALTER COLUMN x DROP NOT NULL;
+```
+
+Rename a table:
+
+```sql
+ALTER TABLE integers RENAME TO integers_old;
+```
+
+Rename a column of a table:
+
+```sql
+ALTER TABLE integers RENAME i TO j;
+```
+
+## Syntax
+
+
+
+`ALTER TABLE` changes the schema of an existing table. All the changes made by `ALTER TABLE` fully respect the transactional semantics, i.e., they will not be visible to other transactions until committed, and can be fully reverted through a rollback.
+
+## `RENAME TABLE`
+
+Rename a table:
+
+```sql
+ALTER TABLE integers RENAME TO integers_old;
+```
+
+The `RENAME TO` clause renames an entire table, changing its name in the schema. Note that any views that rely on the table are **not** automatically updated.
+
+## `RENAME COLUMN`
+
+Rename a column of a table:
+
+```sql
+ALTER TABLE integers RENAME i TO j;
+ALTER TABLE integers RENAME COLUMN j TO k;
+```
+
+The `RENAME COLUMN` clause renames a single column within a table. Any constraints that rely on this name (e.g., `CHECK` constraints) are automatically updated. However, note that any views that rely on this column name are **not** automatically updated.
+
+## `ADD COLUMN`
+
+Add a new column with name `k` to the table `integers`, it will be filled with the default value NULL:
+
+```sql
+ALTER TABLE integers ADD COLUMN k INTEGER;
+```
+
+Add a new column with name `l` to the table integers, it will be filled with the default value 10:
+
+```sql
+ALTER TABLE integers ADD COLUMN l INTEGER DEFAULT 10;
+```
+
+The `ADD COLUMN` clause can be used to add a new column of a specified type to a table. The new column will be filled with the specified default value, or `NULL` if none is specified.
+
+## `DROP COLUMN`
+
+Drop the column `k` from the table `integers`:
+
+```sql
+ALTER TABLE integers DROP k;
+```
+
+The `DROP COLUMN` clause can be used to remove a column from a table. Note that columns can only be removed if they do not have any indexes that rely on them. This includes any indexes created as part of a `PRIMARY KEY` or `UNIQUE` constraint. Columns that are part of multi-column check constraints cannot be dropped either.
+
+## `ALTER TYPE`
+
+Change the type of the column `i` to the type `VARCHAR` using a standard cast:
+
+```sql
+ALTER TABLE integers ALTER i TYPE VARCHAR;
+```
+
+Change the type of the column `i` to the type `VARCHAR`, using the specified expression to convert the data for each row:
+
+```sql
+ALTER TABLE integers ALTER i SET DATA TYPE VARCHAR USING concat(i, '_', j);
+```
+
+The `SET DATA TYPE` clause changes the type of a column in a table. Any data present in the column is converted according to the provided expression in the `USING` clause, or, if the `USING` clause is absent, cast to the new data type. Note that columns can only have their type changed if they do not have any indexes that rely on them and are not part of any `CHECK` constraints.
+
+## `SET` / `DROP DEFAULT`
+
+Set the default value of a column:
+
+```sql
+ALTER TABLE integers ALTER COLUMN i SET DEFAULT 10;
+```
+
+Drop the default value of a column:
+
+```sql
+ALTER TABLE integers ALTER COLUMN i DROP DEFAULT;
+```
+
+The `SET/DROP DEFAULT` clause modifies the `DEFAULT` value of an existing column. Note that this does not modify any existing data in the column. Dropping the default is equivalent to setting the default value to NULL.
+
+> Warning At the moment DuckDB will not allow you to alter a table if there are any dependencies. That means that if you have an index on a column you will first need to drop the index, alter the table, and then recreate the index. Otherwise, you will get a `Dependency Error`.
+
+## `ADD` / `DROP CONSTRAINT`
+
+> The `ADD CONSTRAINT` and `DROP CONSTRAINT` clauses are not yet supported in DuckDB.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/alter_view.md b/docs/archive/1.0/sql/statements/alter_view.md
new file mode 100644
index 00000000000..86f3c86b6b6
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/alter_view.md
@@ -0,0 +1,16 @@
+---
+layout: docu
+title: ALTER VIEW Statement
+---
+
+The `ALTER VIEW` statement changes the schema of an existing view in the catalog.
+
+## Examples
+
+Rename a view:
+
+```sql
+ALTER VIEW v1 RENAME TO v2;
+```
+
+`ALTER VIEW` changes the schema of an existing table. All the changes made by `ALTER VIEW` fully respect the transactional semantics, i.e., they will not be visible to other transactions until committed, and can be fully reverted through a rollback. Note that other views that rely on the table are **not** automatically updated.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/analyze.md b/docs/archive/1.0/sql/statements/analyze.md
new file mode 100644
index 00000000000..aac27e64fac
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/analyze.md
@@ -0,0 +1,16 @@
+---
+layout: docu
+title: ANALYZE Statement
+---
+
+The `ANALYZE` statement recomputes the statistics on DuckDB's tables.
+
+## Usage
+
+The statistics recomputed by the `ANALYZE` statement are only used for [join order optimization](https://blobs.duckdb.org/papers/tom-ebergen-msc-thesis-join-order-optimization-with-almost-no-statistics.pdf). It is therefore recommended to recompute these statistics for improved join orders, especially after performing large updates (inserts and/or deletes).
+
+To recompute the statistics, run:
+
+```sql
+ANALYZE;
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/attach.md b/docs/archive/1.0/sql/statements/attach.md
new file mode 100644
index 00000000000..9b0f9db1a59
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/attach.md
@@ -0,0 +1,227 @@
+---
+layout: docu
+railroad: statements/attach.js
+title: ATTACH/DETACH Statement
+---
+
+DuckDB allows attaching to and detaching from database files.
+
+## Examples
+
+Attach the database `file.db` with the alias inferred from the name (`file`):
+
+```sql
+ATTACH 'file.db';
+```
+
+Attach the database `file.db` with an explicit alias (`file_db`):
+
+```sql
+ATTACH 'file.db' AS file_db;
+```
+
+Attach the database `file.db` in read only mode:
+
+```sql
+ATTACH 'file.db' (READ_ONLY);
+```
+
+Attach a SQLite database for reading and writing (see the [`sqlite` extension]({% link docs/archive/1.0/extensions/sqlite.md %}) for more information):
+
+```sql
+ATTACH 'sqlite_file.db' AS sqlite_db (TYPE SQLITE);
+```
+
+Attach the database `file.db` if inferred database alias `file` does not yet exist:
+
+```sql
+ATTACH IF NOT EXISTS 'file.db';
+```
+
+Attach the database `file.db` if explicit database alias `file_db` does not yet exist:
+
+```sql
+ATTACH IF NOT EXISTS 'file.db' AS file_db;
+```
+
+Create a table in the attached database with alias `file`:
+
+```sql
+CREATE TABLE file.new_table (i INTEGER);
+```
+
+Detach the database with alias `file`:
+
+```sql
+DETACH file;
+```
+
+Show a list of all attached databases:
+
+```sql
+SHOW DATABASES;
+```
+
+Change the default database that is used to the database `file`:
+
+```sql
+USE file;
+```
+
+## Attach
+
+The `ATTACH` statement adds a new database file to the catalog that can be read from and written to.
+Note that attachment definitions are not persisted between sessions: when a new session is launched, you have to re-attach to all databases.
+
+### Attach Syntax
+
+
+
+`ATTACH` allows DuckDB to operate on multiple database files, and allows for transfer of data between different database files.
+
+## Detach
+
+The `DETACH` statement allows previously attached database files to be closed and detached, releasing any locks held on the database file.
+
+Note that it is not possible to detach from the default database: if you would like to do so, issue the [`USE` statement]({% link docs/archive/1.0/sql/statements/use.md %}) to change the default database to another one. For example, if you are connected to a persistent database, you may change to an in-memory database by issuing:
+
+```sql
+ATTACH ':memory:' AS memory_db;
+USE memory_db;
+```
+
+> Warning Closing the connection, e.g., invoking the [`close()` function in Python]({% link docs/archive/1.0/api/python/dbapi.md %}#connection), does not release the locks held on the database files as the file handles are held by the main DuckDB instance (in Python's case, the `duckdb` module).
+
+### Detach Syntax
+
+
+
+## Name Qualification
+
+The fully qualified name of catalog objects contains the *catalog*, the *schema* and the *name* of the object. For example:
+
+Attach the database `new_db`:
+
+```sql
+ATTACH 'new_db.db';
+```
+
+Create the schema `my_schema` in the database `new_db`:
+
+```sql
+CREATE SCHEMA new_db.my_schema;
+```
+
+Create the table `my_table` in the schema `my_schema`:
+
+```sql
+CREATE TABLE new_db.my_schema.my_table (col INTEGER);
+```
+
+Refer to the column `col` inside the table `my_table`:
+
+```sql
+SELECT new_db.my_schema.my_table.col FROM new_db.my_schema.my_table;
+```
+
+Note that often the fully qualified name is not required. When a name is not fully qualified, the system looks for which entries to reference using the *catalog search path*. The default catalog search path includes the system catalog, the temporary catalog and the initially attached database together with the `main` schema.
+
+Also note the rules on [identifiers and database names in particular]({% link docs/archive/1.0/sql/dialect/keywords_and_identifiers.md %}#database-names).
+
+### Default Database and Schema
+
+When a table is created without any qualifications, the table is created in the default schema of the default database. The default database is the database that is launched when the system is created – and the default schema is `main`.
+
+Create the table `my_table` in the default database:
+
+```sql
+CREATE TABLE my_table (col INTEGER);
+```
+
+### Changing the Default Database and Schema
+
+The default database and schema can be changed using the `USE` command.
+
+Set the default database schema to `new_db.main`:
+
+```sql
+USE new_db;
+```
+
+Set the default database schema to `new_db.my_schema`:
+
+```sql
+USE new_db.my_schema;
+```
+
+### Resolving Conflicts
+
+When providing only a single qualification, the system can interpret this as *either* a catalog *or* a schema, as long as there are no conflicts. For example:
+
+```sql
+ATTACH 'new_db.db';
+CREATE SCHEMA my_schema;
+```
+
+Creates the table `new_db.main.tbl`:
+
+```sql
+CREATE TABLE new_db.tbl (i INTEGER);
+```
+
+Creates the table `default_db.my_schema.tbl`:
+
+```sql
+CREATE TABLE my_schema.tbl (i INTEGER);
+```
+
+If we create a conflict (i.e., we have both a schema and a catalog with the same name) the system requests that a fully qualified path is used instead:
+
+```sql
+CREATE SCHEMA new_db;
+CREATE TABLE new_db.tbl (i INTEGER);
+```
+
+```console
+Error: Binder Error: Ambiguous reference to catalog or schema "new_db" -
+use a fully qualified path like "memory.new_db"
+```
+
+### Changing the Catalog Search Path
+
+The catalog search path can be adjusted by setting the `search_path` configuration option, which uses a comma-separated list of values that will be on the search path. The following example demonstrates searching in two databases:
+
+```sql
+ATTACH ':memory:' AS db1;
+ATTACH ':memory:' AS db2;
+CREATE table db1.tbl1 (i INTEGER);
+CREATE table db2.tbl2 (j INTEGER);
+```
+
+Reference the tables using their fully qualified name:
+
+```sql
+SELECT * FROM db1.tbl1;
+SELECT * FROM db2.tbl2;
+```
+
+Or set the search path and reference the tables using their name:
+
+```sql
+SET search_path = 'db1,db2';
+SELECT * FROM tbl1;
+SELECT * FROM tbl2;
+```
+
+## Transactional Semantics
+
+When running queries on multiple databases, the system opens separate transactions per database. The transactions are started *lazily* by default – when a given database is referenced for the first time in a query, a transaction for that database will be started. `SET immediate_transaction_mode = true` can be toggled to change this behavior to eagerly start transactions in all attached databases instead.
+
+While multiple transactions can be active at a time – the system only supports *writing* to a single attached database in a single transaction. If you try to write to multiple attached databases in a single transaction the following error will be thrown:
+
+```console
+Attempting to write to database "db2" in a transaction that has already modified database "db1" -
+a single transaction can only write to a single attached database.
+```
+
+The reason for this restriction is that the system does not maintain atomicity for transactions across attached databases. Transactions are only atomic *within* each database file. By restricting the global transaction to write to only a single database file the atomicity guarantees are maintained.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/call.md b/docs/archive/1.0/sql/statements/call.md
new file mode 100644
index 00000000000..21dc43939da
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/call.md
@@ -0,0 +1,33 @@
+---
+layout: docu
+railroad: statements/call.js
+title: CALL Statement
+---
+
+The `CALL` statement invokes the given table function and returns the results.
+
+## Examples
+
+Invoke the 'duckdb_functions' table function:
+
+```sql
+CALL duckdb_functions();
+```
+
+Invoke the 'pragma_table_info' table function:
+
+```sql
+CALL pragma_table_info('pg_am');
+```
+
+Select only the functions where the name starts with `ST_`:
+
+```sql
+SELECT function_name, parameters, parameter_types, return_type
+FROM duckdb_functions()
+WHERE function_name LIKE 'ST_%';
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/checkpoint.md b/docs/archive/1.0/sql/statements/checkpoint.md
new file mode 100644
index 00000000000..5100ce50fc9
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/checkpoint.md
@@ -0,0 +1,50 @@
+---
+layout: docu
+railroad: statements/checkpoint.js
+title: CHECKPOINT Statement
+---
+
+The `CHECKPOINT` statement synchronizes data in the write-ahead log (WAL) to the database data file. For in-memory
+databases this statement will succeed with no effect.
+
+## Examples
+
+Synchronize data in the default database:
+
+```sql
+CHECKPOINT;
+```
+
+Synchronize data in the specified database:
+
+```sql
+CHECKPOINT file_db;
+```
+
+Abort any in-progress transactions to synchronize the data:
+
+```sql
+FORCE CHECKPOINT;
+```
+
+## Syntax
+
+
+
+Checkpoint operations happen automatically based on the WAL size (see [Configuration]({% link docs/archive/1.0/configuration/overview.md %})). This
+statement is for manual checkpoint actions.
+
+## Behavior
+
+The default `CHECKPOINT` command will fail if there are any running transactions. Including `FORCE` will abort any
+transactions and execute the checkpoint operation.
+
+Also see the related [`PRAGMA` option]({% link docs/archive/1.0/configuration/pragmas.md %}#force-checkpoint) for further behavior modification.
+
+### Reclaiming Space
+
+When performing a checkpoint (automatic or otherwise), the space occupied by deleted rows is partially reclaimed. Note that this does not remove all deleted rows, but rather merges row groups that have a significant amount of deletes together. In the current implementation this requires ~25% of rows to be deleted in adjacent row groups.
+
+When running in in-memory mode, checkpointing has no effect, hence it does not reclaim space after deletes in in-memory databases.
+
+> Warning The [`VACUUM` statement]({% link docs/archive/1.0/sql/statements/vacuum.md %}) does _not_ trigger vacuuming deletes and hence does not reclaim space.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/comment_on.md b/docs/archive/1.0/sql/statements/comment_on.md
new file mode 100644
index 00000000000..103aaffe86c
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/comment_on.md
@@ -0,0 +1,127 @@
+---
+layout: docu
+railroad: statements/comment.js
+title: COMMENT ON Statement
+---
+
+The `COMMENT ON` statement allows adding metadata to catalog entries (tables, columns, etc.).
+It follows the [PostgreSQL syntax](https://www.postgresql.org/docs/16/sql-comment.html).
+
+## Examples
+
+Create a comment on a `TABLE`:
+
+```sql
+COMMENT ON TABLE test_table IS 'very nice table';
+```
+
+Create a comment on a `COLUMN`:
+
+```sql
+COMMENT ON COLUMN test_table.test_table_column IS 'very nice column';
+```
+
+Create a comment on a `VIEW`:
+
+```sql
+COMMENT ON VIEW test_view IS 'very nice view';
+```
+
+Create a comment on an `INDEX`:
+
+```sql
+COMMENT ON INDEX test_index IS 'very nice index';
+```
+
+Create a comment on a `SEQUENCE`:
+
+```sql
+COMMENT ON SEQUENCE test_sequence IS 'very nice sequence';
+```
+
+Create a comment on a `TYPE`:
+
+```sql
+COMMENT ON TYPE test_type IS 'very nice type';
+```
+
+Create a comment on a `MACRO`:
+
+```sql
+COMMENT ON MACRO test_macro IS 'very nice macro';
+```
+
+Create a comment on a `MACRO TABLE`:
+
+```sql
+COMMENT ON MACRO TABLE test_table_macro IS 'very nice table macro';
+```
+
+To unset a comment, set it to `NULL`, e.g.:
+
+```sql
+COMMENT ON TABLE test_table IS NULL;
+```
+
+## Reading Comments
+
+Comments can be read by querying the `comment` column of the respective [metadata functions]({% link docs/archive/1.0/sql/meta/duckdb_table_functions.md %}):
+
+List comments on `TABLE`s:
+
+```sql
+SELECT comment FROM duckdb_tables();
+```
+
+List comments on `COLUMN`s:
+
+```sql
+SELECT comment FROM duckdb_columns();
+```
+
+List comments on `VIEW`s:
+
+```sql
+SELECT comment FROM duckdb_views();
+```
+
+List comments on `INDEX`s:
+
+```sql
+SELECT comment FROM duckdb_indexes();
+```
+
+List comments on `SEQUENCE`s:
+
+```sql
+SELECT comment FROM duckdb_sequences();
+```
+
+List comments on `TYPE`s:
+
+```sql
+SELECT comment FROM duckdb_types();
+```
+
+List comments on `MACRO`s:
+
+```sql
+SELECT comment FROM duckdb_functions();
+```
+
+List comments on `MACRO TABLE`s:
+
+```sql
+SELECT comment FROM duckdb_functions();
+```
+
+## Limitations
+
+The `COMMENT ON` statement currently has the following limitations:
+
+* It is not possible to comment on schemas or databases.
+* It is not possible to comment on things that have a dependency (e.g., a table with an index).
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/copy.md b/docs/archive/1.0/sql/statements/copy.md
new file mode 100644
index 00000000000..67d009eb0d4
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/copy.md
@@ -0,0 +1,350 @@
+---
+layout: docu
+railroad: statements/copy.js
+title: COPY Statement
+---
+
+## Examples
+
+Read a CSV file into the `lineitem` table, using auto-detected CSV options:
+
+```sql
+COPY lineitem FROM 'lineitem.csv';
+```
+
+Read a CSV file into the `lineitem` table, using manually specified CSV options:
+
+```sql
+COPY lineitem FROM 'lineitem.csv' (DELIMITER '|');
+```
+
+Read a Parquet file into the `lineitem` table:
+
+```sql
+COPY lineitem FROM 'lineitem.pq' (FORMAT PARQUET);
+```
+
+Read a JSON file into the `lineitem` table, using auto-detected options:
+
+```sql
+COPY lineitem FROM 'lineitem.json' (FORMAT JSON, AUTO_DETECT true);
+```
+
+Read a CSV file into the `lineitem` table, using double quotes:
+
+```sql
+COPY lineitem FROM "lineitem.csv";
+```
+
+Read a CSV file into the `lineitem` table, omitting quotes:
+
+```sql
+COPY lineitem FROM lineitem.csv;
+```
+
+Write a table to a CSV file:
+
+```sql
+COPY lineitem TO 'lineitem.csv' (FORMAT CSV, DELIMITER '|', HEADER);
+```
+
+Write a table to a CSV file, using double quotes:
+
+```sql
+COPY lineitem TO "lineitem.csv";
+```
+
+Write a table to a CSV file, omitting quotes:
+
+```sql
+COPY lineitem TO lineitem.csv;
+```
+
+Write the result of a query to a Parquet file:
+
+```sql
+COPY (SELECT l_orderkey, l_partkey FROM lineitem) TO 'lineitem.parquet' (COMPRESSION ZSTD);
+```
+
+Copy the entire content of database `db1` to database `db2`:
+
+```sql
+COPY FROM DATABASE db1 TO db2;
+```
+
+Copy only the schema (catalog elements) but not any data:
+
+```sql
+COPY FROM DATABASE db1 TO db2 (SCHEMA);
+```
+
+## Overview
+
+`COPY` moves data between DuckDB and external files. `COPY ... FROM` imports data into DuckDB from an external file. `COPY ... TO` writes data from DuckDB to an external file. The `COPY` command can be used for `CSV`, `PARQUET` and `JSON` files.
+
+## `COPY ... FROM`
+
+`COPY ... FROM` imports data from an external file into an existing table. The data is appended to whatever data is in the table already. The amount of columns inside the file must match the amount of columns in the table `table_name`, and the contents of the columns must be convertible to the column types of the table. In case this is not possible, an error will be thrown.
+
+If a list of columns is specified, `COPY` will only copy the data in the specified columns from the file. If there are any columns in the table that are not in the column list, `COPY ... FROM` will insert the default values for those columns
+
+Copy the contents of a comma-separated file `test.csv` without a header into the table `test`:
+
+```sql
+COPY test FROM 'test.csv';
+```
+
+Copy the contents of a comma-separated file with a header into the `category` table:
+
+```sql
+COPY category FROM 'categories.csv' (HEADER);
+```
+
+Copy the contents of `lineitem.tbl` into the `lineitem` table, where the contents are delimited by a pipe character (`|`):
+
+```sql
+COPY lineitem FROM 'lineitem.tbl' (DELIMITER '|');
+```
+
+Copy the contents of `lineitem.tbl` into the `lineitem` table, where the delimiter, quote character, and presence of a header are automatically detected:
+
+```sql
+COPY lineitem FROM 'lineitem.tbl' (AUTO_DETECT true);
+```
+
+Read the contents of a comma-separated file `names.csv` into the `name` column of the `category` table. Any other columns of this table are filled with their default value:
+
+```sql
+COPY category(name) FROM 'names.csv';
+```
+
+Read the contents of a Parquet file `lineitem.parquet` into the `lineitem` table:
+
+```sql
+COPY lineitem FROM 'lineitem.parquet' (FORMAT PARQUET);
+```
+
+Read the contents of a newline-delimited JSON file `lineitem.ndjson` into the `lineitem` table:
+
+```sql
+COPY lineitem FROM 'lineitem.ndjson' (FORMAT JSON);
+```
+
+Read the contents of a JSON file `lineitem.json` into the `lineitem` table:
+
+```sql
+COPY lineitem FROM 'lineitem.json' (FORMAT JSON, ARRAY true);
+```
+
+### Syntax
+
+
+
+## `COPY ... TO`
+
+`COPY ... TO` exports data from DuckDB to an external CSV or Parquet file. It has mostly the same set of options as `COPY ... FROM`, however, in the case of `COPY ... TO` the options specify how the file should be written to disk. Any file created by `COPY ... TO` can be copied back into the database by using `COPY ... FROM` with a similar set of options.
+
+The `COPY ... TO` function can be called specifying either a table name, or a query. When a table name is specified, the contents of the entire table will be written into the resulting file. When a query is specified, the query is executed and the result of the query is written to the resulting file.
+
+Copy the contents of the `lineitem` table to a CSV file with a header:
+
+```sql
+COPY lineitem TO 'lineitem.csv';
+```
+
+Copy the contents of the `lineitem` table to the file `lineitem.tbl`, where the columns are delimited by a pipe character (`|`), including a header line:
+
+```sql
+COPY lineitem TO 'lineitem.tbl' (DELIMITER '|');
+```
+
+Use tab separators to create a TSV file without a header:
+
+```sql
+COPY lineitem TO 'lineitem.tsv' (DELIMITER '\t', HEADER false);
+```
+
+Copy the l_orderkey column of the `lineitem` table to the file `orderkey.tbl`:
+
+```sql
+COPY lineitem(l_orderkey) TO 'orderkey.tbl' (DELIMITER '|');
+```
+
+Copy the result of a query to the file `query.csv`, including a header with column names:
+
+```sql
+COPY (SELECT 42 AS a, 'hello' AS b) TO 'query.csv' (DELIMITER ',');
+```
+
+Copy the result of a query to the Parquet file `query.parquet`:
+
+```sql
+COPY (SELECT 42 AS a, 'hello' AS b) TO 'query.parquet' (FORMAT PARQUET);
+```
+
+Copy the result of a query to the newline-delimited JSON file `query.ndjson`:
+
+```sql
+COPY (SELECT 42 AS a, 'hello' AS b) TO 'query.ndjson' (FORMAT JSON);
+```
+
+Copy the result of a query to the JSON file `query.json`:
+
+```sql
+COPY (SELECT 42 AS a, 'hello' AS b) TO 'query.json' (FORMAT JSON, ARRAY true);
+```
+
+### `COPY ... TO` Options
+
+Zero or more copy options may be provided as a part of the copy operation. The `WITH` specifier is optional, but if any options are specified, the parentheses are required. Parameter values can be passed in with or without wrapping in single quotes.
+
+Any option that is a Boolean can be enabled or disabled in multiple ways. You can write `true`, `ON`, or `1` to enable the option, and `false`, `OFF`, or `0` to disable it. The `BOOLEAN` value can also be omitted, e.g., by only passing `(HEADER)`, in which case `true` is assumed.
+
+The below options are applicable to all formats written with `COPY`.
+
+| Name | Description | Type | Default |
+|:--|:-----|:-|:-|
+| `FILE_SIZE_BYTES` | If this parameter is set, the `COPY` process creates a directory which will contain the exported files. If a file exceeds the set limit (specified as bytes such as `1000` or in human-readable format such as `1k`), the process creates a new file in the directory. This parameter works in combination with `PER_THREAD_OUTPUT`. Note that the size is used as an approximation, and files can be occasionally slightly over the limit. | `VARCHAR` or `BIGINT` | (empty) |
+| `FORMAT` | Specifies the copy function to use. The default is selected from the file extension (e.g., `.parquet` results in a Parquet file being written/read). If the file extension is unknown `CSV` is selected. Available options are `CSV`, `PARQUET` and `JSON`. | `VARCHAR` | auto |
+| `OVERWRITE_OR_IGNORE` | Whether or not to allow overwriting a directory if one already exists. Only has an effect when used with `partition_by`. | `BOOL` | `false` |
+| `PARTITION_BY` | The columns to partition by using a Hive partitioning scheme, see the [partitioned writes section]({% link docs/archive/1.0/data/partitioning/partitioned_writes.md %}). | `VARCHAR[]` | (empty) |
+| `PER_THREAD_OUTPUT` | Generate one file per thread, rather than one file in total. This allows for faster parallel writing. | `BOOL` | `false` |
+| `USE_TMP_FILE` | Whether or not to write to a temporary file first if the original file exists (`target.csv.tmp`). This prevents overwriting an existing file with a broken file in case the writing is cancelled. | `BOOL` | `auto` |
+
+### Syntax
+
+
+
+## `COPY FROM DATABASE ... TO`
+
+The `COPY FROM DATABASE ... TO` statement copies the entire content from one attached database to another attached database. This includes the schema, including constraints, indexes, sequences, macros, and the data itself.
+
+```sql
+ATTACH 'db1.db' AS db1;
+CREATE TABLE db1.tbl AS SELECT 42 AS x, 3 AS y;
+CREATE MACRO db1.two_x_plus_y(x, y) AS 2 * x + y;
+
+ATTACH 'db2.db' AS db2;
+COPY FROM DATABASE db1 TO db2;
+SELECT db2.two_x_plus_y(x, y) AS z FROM db2.tbl;
+```
+
+| z |
+|---:|
+| 87 |
+
+To only copy the **schema** of `db1` to `db2` but omit copying the data, add `SCHEMA` to the statement:
+
+```sql
+COPY FROM DATABASE db1 TO db2 (SCHEMA);
+```
+
+### Syntax
+
+
+
+## Format-Specific Options
+
+### CSV Options
+
+The below options are applicable when writing `CSV` files.
+
+| Name | Description | Type | Default |
+|:--|:-----|:-|:-|
+| `COMPRESSION` | The compression type for the file. By default this will be detected automatically from the file extension (e.g., `file.csv.gz` will use gzip, `file.csv` will use `none`). Options are `none`, `gzip`, `zstd`. | `VARCHAR` | `auto` |
+| `DATEFORMAT` | Specifies the date format to use when writing dates. See [Date Format]({% link docs/archive/1.0/sql/functions/dateformat.md %}) | `VARCHAR` | (empty) |
+| `DELIM` or `SEP` | The character that is written to separate columns within each row. | `VARCHAR` | `,` |
+| `ESCAPE` | The character that should appear before a character that matches the `quote` value. | `VARCHAR` | `"` |
+| `FORCE_QUOTE` | The list of columns to always add quotes to, even if not required. | `VARCHAR[]` | `[]` |
+| `HEADER` | Whether or not to write a header for the CSV file. | `BOOL` | `true` |
+| `NULLSTR` | The string that is written to represent a `NULL` value. | `VARCHAR` | (empty) |
+| `QUOTE` | The quoting character to be used when a data value is quoted. | `VARCHAR` | `"` |
+| `TIMESTAMPFORMAT` | Specifies the date format to use when writing timestamps. See [Date Format]({% link docs/archive/1.0/sql/functions/dateformat.md %}) | `VARCHAR` | (empty) |
+
+### Parquet Options
+
+The below options are applicable when writing `Parquet` files.
+
+| Name | Description | Type | Default |
+|:--|:-----|:-|:-|
+| `COMPRESSION` | The compression format to use (`uncompressed`, `snappy`, `gzip` or `zstd`). | `VARCHAR` | `snappy` |
+| `COMPRESSION_LEVEL` | Compression level, set between 1 (lowest compression, fastest) and 22 (highest compression, slowest). Only supported for zstd compression. | `BIGINT` | `3` |
+| `FIELD_IDS` | The `field_id` for each column. Pass `auto` to attempt to infer automatically. | `STRUCT` | (empty) |
+| `ROW_GROUP_SIZE_BYTES` | The target size of each row group. You can pass either a human-readable string, e.g., `2MB`, or an integer, i.e., the number of bytes. This option is only used when you have issued `SET preserve_insertion_order = false;`, otherwise, it is ignored. | `BIGINT` | `row_group_size * 1024` |
+| `ROW_GROUP_SIZE` | The target size, i.e., number of rows, of each row group. | `BIGINT` | 122880 |
+
+Some examples of `FIELD_IDS` are:
+
+Assign `field_ids` automatically:
+
+```sql
+COPY
+ (SELECT 128 AS i)
+ TO 'my.parquet'
+ (FIELD_IDS 'auto');
+```
+
+Sets the `field_id` of column `i` to 42:
+
+```sql
+COPY
+ (SELECT 128 AS i)
+ TO 'my.parquet'
+ (FIELD_IDS {i: 42});
+```
+
+Sets the `field_id` of column `i` to 42, and column `j` to 43:
+
+```sql
+COPY
+ (SELECT 128 AS i, 256 AS j)
+ TO 'my.parquet'
+ (FIELD_IDS {i: 42, j: 43});
+```
+
+Sets the `field_id` of column `my_struct` to 43, and column `i` (nested inside `my_struct`) to 43:
+
+```sql
+COPY
+ (SELECT {i: 128} AS my_struct)
+ TO 'my.parquet'
+ (FIELD_IDS {my_struct: {__duckdb_field_id: 42, i: 43}});
+```
+
+Sets the `field_id` of column `my_list` to 42, and column `element` (default name of list child) to 43:
+
+```sql
+COPY
+ (SELECT [128, 256] AS my_list)
+ TO 'my.parquet'
+ (FIELD_IDS {my_list: {__duckdb_field_id: 42, element: 43}});
+```
+
+Sets the `field_id` of column `my_map` to 42, and columns `key` and `value` (default names of map children) to 43 and 44:
+
+```sql
+COPY
+ (SELECT MAP {'key1' : 128, 'key2': 256} my_map)
+ TO 'my.parquet'
+ (FIELD_IDS {my_map: {__duckdb_field_id: 42, key: 43, value: 44}});
+```
+
+### JSON Options
+
+The below options are applicable when writing `JSON` files.
+
+| Name | Description | Type | Default |
+|:--|:-----|:-|:-|
+| `ARRAY` | Whether to write a JSON array. If `true`, a JSON array of records is written, if `false`, newline-delimited JSON is written | `BOOL` | `false` |
+| `COMPRESSION` | The compression type for the file. By default this will be detected automatically from the file extension (e.g., `file.json.gz` will use gzip, `file.json` will use `none`). Options are `none`, `gzip`, `zstd`. | `VARCHAR` | `auto` |
+| `DATEFORMAT` | Specifies the date format to use when writing dates. See [Date Format]({% link docs/archive/1.0/sql/functions/dateformat.md %}) | `VARCHAR` | (empty) |
+| `TIMESTAMPFORMAT` | Specifies the date format to use when writing timestamps. See [Date Format]({% link docs/archive/1.0/sql/functions/dateformat.md %}) | `VARCHAR` | (empty) |
+
+## Limitations
+
+`COPY` does not support copying between tables. To copy between tables, use an [`INSERT statement`]({% link docs/archive/1.0/sql/statements/insert.md %}):
+
+```sql
+INSERT INTO tbl2
+ FROM tbl1;
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_index.md b/docs/archive/1.0/sql/statements/create_index.md
new file mode 100644
index 00000000000..d9a72468bdc
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_index.md
@@ -0,0 +1,80 @@
+---
+layout: docu
+railroad: statements/indexes.js
+title: CREATE INDEX Statement
+---
+
+## `CREATE INDEX`
+
+The `CREATE INDEX` statement constructs an index on the specified column(s) of the specified table. Compound indexes on multiple columns/expressions are supported.
+
+> Unidimensional indexes are supported, while multidimensional indexes are not yet supported.
+
+### Examples
+
+Create a unique index `films_id_idx` on the column id of table `films`:
+
+```sql
+CREATE UNIQUE INDEX films_id_idx ON films (id);
+```
+
+Create index `s_idx` that allows for duplicate values on column `revenue` of table `films`:
+
+```sql
+CREATE INDEX s_idx ON films (revenue);
+```
+
+Create compound index `gy_idx` on `genre` and `year` columns:
+
+```sql
+CREATE INDEX gy_idx ON films (genre, year);
+```
+
+Create index `i_index` on the expression of the sum of columns `j` and `k` from table `integers`:
+
+```sql
+CREATE INDEX i_index ON integers ((j + k));
+```
+
+### Parameters
+
+
+
+| Name | Description |
+|:-|:-----|
+| `UNIQUE` | Causes the system to check for duplicate values in the table when the index is created (if data already exist) and each time data is added. Attempts to insert or update data that would result in duplicate entries will generate an error. |
+| `name` | The name of the index to be created. |
+| `table` | The name of the table to be indexed. |
+| `column` | The name of the column to be indexed. |
+| `expression` | An expression based on one or more columns of the table. The expression usually must be written with surrounding parentheses, as shown in the syntax. However, the parentheses can be omitted if the expression has the form of a function call. |
+| `index type` | Specified index type, see [Indexes]({% link docs/archive/1.0/sql/indexes.md %}). Optional. |
+| `option` | Index option in the form of a boolean true value (e.g., `is_cool`) or a key-value pair (e.g., `my_option = 2`). Optional. |
+
+### Syntax
+
+
+
+## `DROP INDEX`
+
+`DROP INDEX` drops an existing index from the database system.
+
+### Examples
+
+Remove the index `title_idx`:
+
+```sql
+DROP INDEX title_idx;
+```
+
+### Parameters
+
+
+
+| Name | Description |
+|:---|:---|
+| `IF EXISTS` | Do not throw an error if the index does not exist. |
+| `name` | The name of an index to remove. |
+
+### Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_macro.md b/docs/archive/1.0/sql/statements/create_macro.md
new file mode 100644
index 00000000000..ff52305f15b
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_macro.md
@@ -0,0 +1,246 @@
+---
+layout: docu
+railroad: statements/createmacro.js
+title: CREATE MACRO Statement
+---
+
+The `CREATE MACRO` statement can create a scalar or table macro (function) in the catalog.
+A macro may only be a single `SELECT` statement (similar to a `VIEW`), but it has the benefit of accepting parameters.
+For a scalar macro, `CREATE MACRO` is followed by the name of the macro, and optionally parameters within a set of parentheses. The keyword `AS` is next, followed by the text of the macro. By design, a scalar macro may only return a single value.
+For a table macro, the syntax is similar to a scalar macro except `AS` is replaced with `AS TABLE`. A table macro may return a table of arbitrary size and shape.
+
+> If a `MACRO` is temporary, it is only usable within the same database connection and is deleted when the connection is closed.
+
+## Examples
+
+### Scalar Macros
+
+Create a macro that adds two expressions (`a` and `b`):
+
+```sql
+CREATE MACRO add(a, b) AS a + b;
+```
+
+Create a macro for a case expression:
+
+```sql
+CREATE MACRO ifelse(a, b, c) AS CASE WHEN a THEN b ELSE c END;
+```
+
+Create a macro that does a subquery:
+
+```sql
+CREATE MACRO one() AS (SELECT 1);
+```
+
+Create a macro with a common table expression.
+Note that parameter names get priority over column names. To work around this, disambiguate using the table name.
+
+```sql
+CREATE MACRO plus_one(a) AS (WITH cte AS (SELECT 1 AS a) SELECT cte.a + a FROM cte);
+```
+
+Macros are schema-dependent, and have an alias, `FUNCTION`:
+
+```sql
+CREATE FUNCTION main.my_avg(x) AS sum(x) / count(x);
+```
+
+Create a macro with default constant parameters:
+
+```sql
+CREATE MACRO add_default(a, b := 5) AS a + b;
+```
+
+Create a macro `arr_append` (with a functionality equivalent to `array_append`):
+
+```sql
+CREATE MACRO arr_append(l, e) AS list_concat(l, list_value(e));
+```
+
+### Table Macros
+
+Create a table macro without parameters:
+
+```sql
+CREATE MACRO static_table() AS TABLE
+ SELECT 'Hello' AS column1, 'World' AS column2;
+```
+
+Create a table macro with parameters (that can be of any type):
+
+```sql
+CREATE MACRO dynamic_table(col1_value, col2_value) AS TABLE
+ SELECT col1_value AS column1, col2_value AS column2;
+```
+
+Create a table macro that returns multiple rows. It will be replaced if it already exists, and it is temporary (will be automatically deleted when the connection ends):
+
+```sql
+CREATE OR REPLACE TEMP MACRO dynamic_table(col1_value, col2_value) AS TABLE
+ SELECT col1_value AS column1, col2_value AS column2
+ UNION ALL
+ SELECT 'Hello' AS col1_value, 456 AS col2_value;
+```
+
+Pass an argument as a list:
+
+```sql
+CREATE MACRO get_users(i) AS TABLE
+ SELECT * FROM users WHERE uid IN (SELECT unnest(i));
+```
+
+An example for how to use the `get_users` table macro is the following:
+
+```sql
+CREATE TABLE users AS
+ SELECT *
+ FROM (VALUES (1, 'Ada'), (2, 'Bob'), (3, 'Carl'), (4, 'Dan'), (5, 'Eve')) t(uid, name);
+SELECT * FROM get_users([1, 5]);
+```
+
+## Syntax
+
+
+
+Macros allow you to create shortcuts for combinations of expressions.
+
+```sql
+CREATE MACRO add(a) AS a + b;
+```
+
+```console
+Binder Error: Referenced column "b" not found in FROM clause!
+```
+
+This works:
+
+```sql
+CREATE MACRO add(a, b) AS a + b;
+```
+
+Usage example:
+
+```sql
+SELECT add(1, 2) AS x;
+```
+
+| x |
+|--:|
+| 3 |
+
+However, this fails:
+
+```sql
+SELECT add('hello', 3);
+```
+
+```console
+Binder Error: Could not choose a best candidate function for the function call "+(STRING_LITERAL, INTEGER_LITERAL)". In order to select one, please add explicit type casts.
+ Candidate functions:
+ +(DATE, INTEGER) -> DATE
+ +(INTEGER, INTEGER) -> INTEGER
+```
+
+Macros can have default parameters.
+Unlike some languages, default parameters must be named
+when the macro is invoked.
+
+`b` is a default parameter:
+
+```sql
+CREATE MACRO add_default(a, b := 5) AS a + b;
+```
+
+The following will result in 42:
+
+```sql
+SELECT add_default(37);
+```
+
+The following will throw an error:
+
+```sql
+SELECT add_default(40, 2);
+```
+
+```console
+Binder Error: Macro function 'add_default(a)' requires a single positional argument, but 2 positional arguments were provided.
+```
+
+Default parameters must used by assigning them like the following:
+
+```sql
+SELECT add_default(40, b := 2) AS x;
+```
+
+| x |
+|---:|
+| 42 |
+
+However, the following fails:
+
+```sql
+SELECT add_default(b := 2, 40);
+```
+
+```console
+Binder Error: Positional parameters cannot come after parameters with a default value!
+```
+
+The order of default parameters does not matter:
+
+```sql
+CREATE MACRO triple_add(a, b := 5, c := 10) AS a + b + c;
+```
+
+```sql
+SELECT triple_add(40, c := 1, b := 1) AS x;
+```
+
+| x |
+|---:|
+| 42 |
+
+When macros are used, they are expanded (i.e., replaced with the original expression), and the parameters within the expanded expression are replaced with the supplied arguments. Step by step:
+
+The `add` macro we defined above is used in a query:
+
+```sql
+SELECT add(40, 2) AS x;
+```
+
+Internally, add is replaced with its definition of `a + b`:
+
+```sql
+SELECT a + b; AS x
+```
+
+Then, the parameters are replaced by the supplied arguments:
+
+```sql
+SELECT 40 + 2 AS x;
+```
+
+## Limitations
+
+### Using Named Parameters
+
+Currently, positional macro parameters can only be used positionally, and named parameters can only be used by supplying their name. Therefore, the following will not work:
+
+```sql
+CREATE MACRO my_macro(a, b := 42) AS (a + b);
+SELECT my_macro(32, 52);
+```
+
+```console
+Error: Binder Error: Macro function 'my_macro(a)' requires a single positional argument, but 2 positional arguments were provided.
+```
+
+### Using Subquery Macros
+
+If a `MACRO` is defined as a subquery, it cannot be invoked in a table function. DuckDB will return the following error:
+
+```console
+Binder Error: Table function cannot contain subqueries
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_schema.md b/docs/archive/1.0/sql/statements/create_schema.md
new file mode 100644
index 00000000000..8bb3a07a60d
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_schema.md
@@ -0,0 +1,40 @@
+---
+layout: docu
+railroad: statements/createschema.js
+title: CREATE SCHEMA Statement
+---
+
+The `CREATE SCHEMA` statement creates a schema in the catalog. The default schema is `main`.
+
+## Examples
+
+Create a schema:
+
+```sql
+CREATE SCHEMA s1;
+```
+
+Create a schema if it does not exist yet:
+
+```sql
+CREATE SCHEMA IF NOT EXISTS s2;
+```
+
+Create table in the schemas:
+
+```sql
+CREATE TABLE s1.t (id INTEGER PRIMARY KEY, other_id INTEGER);
+CREATE TABLE s2.t (id INTEGER PRIMARY KEY, j VARCHAR);
+```
+
+Compute a join between tables from two schemas:
+
+```sql
+SELECT *
+FROM s1.t s1t, s2.t s2t
+WHERE s1t.other_id = s2t.id;
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_secret.md b/docs/archive/1.0/sql/statements/create_secret.md
new file mode 100644
index 00000000000..5924a960c67
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_secret.md
@@ -0,0 +1,15 @@
+---
+layout: docu
+railroad: statements/secrets.js
+title: CREATE SECRET Statement
+---
+
+The `CREATE SECRET` statement creates a new secret in the [Secrets Manager]({% link docs/archive/1.0/configuration/secrets_manager.md %}).
+
+### Syntax for `CREATE SECRET`
+
+
+
+### Syntax for `DROP SECRET`
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_sequence.md b/docs/archive/1.0/sql/statements/create_sequence.md
new file mode 100644
index 00000000000..aade87ae51d
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_sequence.md
@@ -0,0 +1,164 @@
+---
+layout: docu
+railroad: statements/createsequence.js
+title: CREATE SEQUENCE Statement
+---
+
+The `CREATE SEQUENCE` statement creates a new sequence number generator.
+
+### Examples
+
+Generate an ascending sequence starting from 1:
+
+```sql
+CREATE SEQUENCE serial;
+```
+
+Generate sequence from a given start number:
+
+```sql
+CREATE SEQUENCE serial START 101;
+```
+
+Generate odd numbers using `INCREMENT BY`:
+
+```sql
+CREATE SEQUENCE serial START WITH 1 INCREMENT BY 2;
+```
+
+Generate a descending sequqnce starting from 99:
+
+```sql
+CREATE SEQUENCE serial START WITH 99 INCREMENT BY -1 MAXVALUE 99;
+```
+
+By default, cycles are not allowed and will result in error, e.g.:
+
+```console
+Sequence Error: nextval: reached maximum value of sequence "serial" (10)
+```
+
+```sql
+CREATE SEQUENCE serial START WITH 1 MAXVALUE 10;
+```
+
+`CYCLE` allows cycling through the same sequence repeatedly:
+
+```sql
+CREATE SEQUENCE serial START WITH 1 MAXVALUE 10 CYCLE;
+```
+
+### Creating and Dropping Sequences
+
+Sequences can be created and dropped similarly to other catalogue items.
+
+Overwrite an existing sequence:
+
+```sql
+CREATE OR REPLACE SEQUENCE serial;
+```
+
+Only create sequence if no such sequence exists yet:
+
+```sql
+CREATE SEQUENCE IF NOT EXISTS serial;
+```
+
+Remove sequence:
+
+```sql
+DROP SEQUENCE serial;
+```
+
+Remove sequence if exists:
+
+```sql
+DROP SEQUENCE IF EXISTS serial;
+```
+
+### Using Sequences for Primary Keys
+
+Sequences can provide an integer primary key for a table. For example:
+
+```sql
+CREATE SEQUENCE id_sequence START 1;
+CREATE TABLE tbl (id INTEGER DEFAULT nextval('id_sequence'), s VARCHAR);
+INSERT INTO tbl (s) VALUES ('hello'), ('world');
+SELECT * FROM tbl;
+```
+
+The script results in the following table:
+
+| id | s |
+|---:|-------|
+| 1 | hello |
+| 2 | world |
+
+Sequences can also be added using the [`ALTER TABLE` statement]({% link docs/archive/1.0/sql/statements/alter_table.md %}). The following example adds an `id` column and fills it with values generated by the sequence:
+
+```sql
+CREATE TABLE tbl (s VARCHAR);
+INSERT INTO tbl VALUES ('hello'), ('world');
+CREATE SEQUENCE id_sequence START 1;
+ALTER TABLE tbl ADD COLUMN id INTEGER DEFAULT nextval('id_sequence');
+SELECT * FROM tbl;
+```
+
+This script results in the same table as the previous example.
+
+### Selecting the Next Value
+
+To select the next number from a sequence, use `nextval`:
+
+```sql
+CREATE SEQUENCE serial START 1;
+SELECT nextval('serial') AS nextval;
+```
+
+| nextval |
+|--------:|
+| 1 |
+
+Using this sequence in an `INSERT` command:
+
+```sql
+INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
+```
+
+### Selecting the Current Value
+
+You may also view the current number from the sequence. Note that the `nextval` function must have already been called before calling `currval`, otherwise a Serialization Error (`sequence is not yet defined in this session`) will be thrown.
+
+```sql
+CREATE SEQUENCE serial START 1;
+SELECT nextval('serial') AS nextval;
+SELECT currval('serial') AS currval;
+```
+
+| currval |
+|--------:|
+| 1 |
+
+### Syntax
+
+
+
+`CREATE SEQUENCE` creates a new sequence number generator.
+
+If a schema name is given then the sequence is created in the specified schema. Otherwise it is created in the current schema. Temporary sequences exist in a special schema, so a schema name may not be given when creating a temporary sequence. The sequence name must be distinct from the name of any other sequence in the same schema.
+
+After a sequence is created, you use the function `nextval` to operate on the sequence.
+
+## Parameters
+
+| Name | Description |
+|:--|:-----|
+| `CYCLE` or `NO CYCLE` | The `CYCLE` option allows the sequence to wrap around when the `maxvalue` or `minvalue` has been reached by an ascending or descending sequence respectively. If the limit is reached, the next number generated will be the `minvalue` or `maxvalue`, respectively. If `NO CYCLE` is specified, any calls to `nextval` after the sequence has reached its maximum value will return an error. If neither `CYCLE` or `NO CYCLE` are specified, `NO CYCLE` is the default. |
+| `increment` | The optional clause `INCREMENT BY increment` specifies which value is added to the current sequence value to create a new value. A positive value will make an ascending sequence, a negative one a descending sequence. The default value is 1. |
+| `maxvalue` | The optional clause `MAXVALUE maxvalue` determines the maximum value for the sequence. If this clause is not supplied or `NO MAXVALUE` is specified, then default values will be used. The defaults are 2^63 - 1 and -1 for ascending and descending sequences, respectively. |
+| `minvalue` | The optional clause `MINVALUE minvalue` determines the minimum value a sequence can generate. If this clause is not supplied or `NO MINVALUE` is specified, then defaults will be used. The defaults are 1 and -(2^63 - 1) for ascending and descending sequences, respectively. |
+| `name` | The name (optionally schema-qualified) of the sequence to be created. |
+| `start` | The optional clause `START WITH start` allows the sequence to begin anywhere. The default starting value is `minvalue` for ascending sequences and `maxvalue` for descending ones. |
+| `TEMPORARY` or `TEMP` | If specified, the sequence object is created only for this session, and is automatically dropped on session exit. Existing permanent sequences with the same name are not visible (in this session) while the temporary sequence exists, unless they are referenced with schema-qualified names. |
+
+> Sequences are based on `BIGINT` arithmetic, so the range cannot exceed the range of an eight-byte integer (-9223372036854775808 to 9223372036854775807).
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_table.md b/docs/archive/1.0/sql/statements/create_table.md
new file mode 100644
index 00000000000..a1ae3f1edda
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_table.md
@@ -0,0 +1,289 @@
+---
+layout: docu
+railroad: statements/createtable.js
+title: CREATE TABLE Statement
+---
+
+The `CREATE TABLE` statement creates a table in the catalog.
+
+## Examples
+
+Create a table with two integer columns (`i` and `j`):
+
+```sql
+CREATE TABLE t1 (i INTEGER, j INTEGER);
+```
+
+Create a table with a primary key:
+
+```sql
+CREATE TABLE t1 (id INTEGER PRIMARY KEY, j VARCHAR);
+```
+
+Create a table with a composite primary key:
+
+```sql
+CREATE TABLE t1 (id INTEGER, j VARCHAR, PRIMARY KEY (id, j));
+```
+
+Create a table with various different types and constraints:
+
+```sql
+CREATE TABLE t1 (
+ i INTEGER NOT NULL,
+ decimalnr DOUBLE CHECK (decimalnr < 10),
+ date DATE UNIQUE,
+ time TIMESTAMP
+);
+```
+
+Create table with `CREATE TABLE ... AS SELECT` (CTAS):
+
+```sql
+CREATE TABLE t1 AS
+ SELECT 42 AS i, 84 AS j;
+```
+
+Create a table from a CSV file (automatically detecting column names and types):
+
+```sql
+CREATE TABLE t1 AS
+ SELECT *
+ FROM read_csv('path/file.csv');
+```
+
+We can use the `FROM`-first syntax to omit `SELECT *`:
+
+```sql
+CREATE TABLE t1 AS
+ FROM read_csv('path/file.csv');
+```
+
+Copy the schema of `t2` to `t1`:
+
+```sql
+CREATE TABLE t1 AS
+ FROM t2
+ LIMIT 0;
+```
+
+## Temporary Tables
+
+Temporary tables can be created using the `CREATE TEMP TABLE` or the `CREATE TEMPORARY TABLE` statement (see diagram below).
+Temporary tables are session scoped (similar to PostgreSQL for example), meaning that only the specific connection that created them can access them, and once the connection to DuckDB is closed they will be automatically dropped.
+Temporary tables reside in memory rather than on disk (even when connecting to a persistent DuckDB), but if the `temp_directory` [configuration]({% link docs/archive/1.0/configuration/overview.md %}) is set when connecting or with a `SET` command, data will be spilled to disk if memory becomes constrained.
+
+Create a temporary table from a CSV file (automatically detecting column names and types):
+
+```sql
+CREATE TEMP TABLE t1 AS
+ SELECT *
+ FROM read_csv('path/file.csv');
+```
+
+Allow temporary tables to off-load excess memory to disk:
+
+```sql
+SET temp_directory = '/path/to/directory/';
+```
+
+Temporary tables are part of the `temp.main` schema. While discouraged, their names can overlap with the names of the regular database tables. In these cases, use their fully qualified name, e.g., `temp.main.t1`, for disambiguation.
+
+## `CREATE OR REPLACE`
+
+The `CREATE OR REPLACE` syntax allows a new table to be created or for an existing table to be overwritten by the new table. This is shorthand for dropping the existing table and then creating the new one.
+
+Create a table with two integer columns (i and j) even if t1 already exists:
+
+```sql
+CREATE OR REPLACE TABLE t1 (i INTEGER, j INTEGER);
+```
+
+## `IF NOT EXISTS`
+
+The `IF NOT EXISTS` syntax will only proceed with the creation of the table if it does not already exist. If the table already exists, no action will be taken and the existing table will remain in the database.
+
+Create a table with two integer columns (`i` and `j`) only if `t1` does not exist yet:
+
+```sql
+CREATE TABLE IF NOT EXISTS t1 (i INTEGER, j INTEGER);
+```
+
+## `CREATE TABLE ... AS SELECT` (CTAS)
+
+DuckDB supports the `CREATE TABLE ... AS SELECT` syntax, also known as “CTAS”:
+
+```sql
+CREATE TABLE nums AS
+ SELECT i
+ FROM range(0, 3) t(i);
+```
+
+This syntax can be used in combination with the [CSV reader]({% link docs/archive/1.0/data/csv/overview.md %}), the shorthand to read directly from CSV files without specifying a function, the [`FROM`-first syntax]({% link docs/archive/1.0/sql/query_syntax/from.md %}), and the [HTTP(S) support]({% link docs/archive/1.0/extensions/httpfs/https.md %}), yielding concise SQL commands such as the following:
+
+```sql
+CREATE TABLE flights AS
+ FROM 'https://duckdb.org/data/flights.csv';
+```
+
+The CTAS construct also works with the `OR REPLACE` modifier, yielding `CREATE OR REPLACE TABLE ... AS` statements:
+
+```sql
+CREATE OR REPLACE TABLE flights AS
+ FROM 'https://duckdb.org/data/flights.csv';
+```
+
+Note that it is not possible to create tables using CTAS statements with constraints (primary keys, check constraints, etc.).
+
+## Check Constraints
+
+A `CHECK` constraint is an expression that must be satisfied by the values of every row in the table.
+
+```sql
+CREATE TABLE t1 (
+ id INTEGER PRIMARY KEY,
+ percentage INTEGER CHECK (0 <= percentage AND percentage <= 100)
+);
+INSERT INTO t1 VALUES (1, 5);
+INSERT INTO t1 VALUES (2, -1);
+```
+
+```console
+Error: Constraint Error: CHECK constraint failed: t1
+```
+
+```sql
+INSERT INTO t1 VALUES (3, 101);
+```
+
+```console
+Error: Constraint Error: CHECK constraint failed: t1
+```
+
+```sql
+CREATE TABLE t2 (id INTEGER PRIMARY KEY, x INTEGER, y INTEGER CHECK (x < y));
+INSERT INTO t2 VALUES (1, 5, 10);
+INSERT INTO t2 VALUES (2, 5, 3);
+```
+
+```console
+Error: Constraint Error: CHECK constraint failed: t2
+```
+
+`CHECK` constraints can also be added as part of the `CONSTRAINTS` clause:
+
+```sql
+CREATE TABLE t3 (
+ id INTEGER PRIMARY KEY,
+ x INTEGER,
+ y INTEGER,
+ CONSTRAINT x_smaller_than_y CHECK (x < y)
+);
+INSERT INTO t3 VALUES (1, 5, 10);
+INSERT INTO t3 VALUES (2, 5, 3);
+```
+
+```console
+Error: Constraint Error: CHECK constraint failed: t3
+```
+
+## Foreign Key Constraints
+
+A `FOREIGN KEY` is a column (or set of columns) that references another table's primary key. Foreign keys check referential integrity, i.e., the referred primary key must exist in the other table upon insertion.
+
+```sql
+CREATE TABLE t1 (id INTEGER PRIMARY KEY, j VARCHAR);
+CREATE TABLE t2 (
+ id INTEGER PRIMARY KEY,
+ t1_id INTEGER,
+ FOREIGN KEY (t1_id) REFERENCES t1 (id)
+);
+```
+
+Example:
+
+```sql
+INSERT INTO t1 VALUES (1, 'a');
+INSERT INTO t2 VALUES (1, 1);
+INSERT INTO t2 VALUES (2, 2);
+```
+
+```console
+Error: Constraint Error: Violates foreign key constraint because key "id: 2" does not exist in the referenced table
+```
+
+Foreign keys can be defined on composite primary keys:
+
+```sql
+CREATE TABLE t3 (id INTEGER, j VARCHAR, PRIMARY KEY (id, j));
+CREATE TABLE t4 (
+ id INTEGER PRIMARY KEY, t3_id INTEGER, t3_j VARCHAR,
+ FOREIGN KEY (t3_id, t3_j) REFERENCES t3(id, j)
+);
+```
+
+Example:
+
+```sql
+INSERT INTO t3 VALUES (1, 'a');
+INSERT INTO t4 VALUES (1, 1, 'a');
+INSERT INTO t4 VALUES (2, 1, 'b');
+```
+
+```console
+Error: Constraint Error: Violates foreign key constraint because key "id: 1, j: b" does not exist in the referenced table
+```
+
+Foreign keys can also be defined on unique columns:
+
+```sql
+CREATE TABLE t5 (id INTEGER UNIQUE, j VARCHAR);
+CREATE TABLE t6 (
+ id INTEGER PRIMARY KEY,
+ t5_id INTEGER,
+ FOREIGN KEY (t5_id) REFERENCES t5(id)
+);
+```
+
+### Limitations
+
+Foreign keys have the following limitations.
+
+Foreign keys with cascading deletes (`FOREIGN KEY ... REFERENCES ... ON DELETE CASCADE`) are not supported.
+
+Inserting into tables with self-referencing foreign keys is currently not supported and will result in the following error:
+
+```console
+Constraint Error: Violates foreign key constraint because key "..." does not exist in the referenced table.
+```
+
+## Generated Columns
+
+The `[type] [GENERATED ALWAYS] AS (expr) [VIRTUAL|STORED]` syntax will create a generated column. The data in this kind of column is generated from its expression, which can reference other (regular or generated) columns of the table. Since they are produced by calculations, these columns can not be inserted into directly.
+
+DuckDB can infer the type of the generated column based on the expression's return type. This allows you to leave out the type when declaring a generated column. It is possible to explicitly set a type, but insertions into the referenced columns might fail if the type can not be cast to the type of the generated column.
+
+Generated columns come in two varieties: `VIRTUAL` and `STORED`.
+The data of virtual generated columns is not stored on disk, instead it is computed from the expression every time the column is referenced (through a select statement).
+
+The data of stored generated columns is stored on disk and is computed every time the data of their dependencies change (through an `INSERT` / `UPDATE` / `DROP` statement).
+
+Currently, only the `VIRTUAL` kind is supported, and it is also the default option if the last field is left blank.
+
+The simplest syntax for a generated column:
+
+The type is derived from the expression, and the variant defaults to `VIRTUAL`:
+
+```sql
+CREATE TABLE t1 (x FLOAT, two_x AS (2 * x));
+```
+
+Fully specifying the same generated column for completeness:
+
+```sql
+CREATE TABLE t1 (x FLOAT, two_x FLOAT GENERATED ALWAYS AS (2 * x) VIRTUAL);
+```
+
+## Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_type.md b/docs/archive/1.0/sql/statements/create_type.md
new file mode 100644
index 00000000000..6cd250b328f
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_type.md
@@ -0,0 +1,45 @@
+---
+layout: docu
+railroad: statements/createtype.js
+title: CREATE TYPE Statement
+---
+
+The `CREATE TYPE` statement defines a new type in the catalog.
+
+## Examples
+
+Create a simple `ENUM` type:
+
+```sql
+CREATE TYPE mood AS ENUM ('happy', 'sad', 'curious');
+```
+
+Create a simple `STRUCT` type:
+
+```sql
+CREATE TYPE many_things AS STRUCT(k INTEGER, l VARCHAR);
+```
+
+Create a simple `UNION` type:
+
+```sql
+CREATE TYPE one_thing AS UNION(number INTEGER, string VARCHAR);
+```
+
+Create a type alias:
+
+```sql
+CREATE TYPE x_index AS INTEGER;
+```
+
+## Syntax
+
+
+
+The `CREATE TYPE` clause defines a new data type available to this DuckDB instance.
+These new types can then be inspected in the [`duckdb_types` table]({% link docs/archive/1.0/sql/meta/duckdb_table_functions.md %}#duckdb_types).
+
+## Limitations
+
+Extending types to support custom operators (such as the PostgreSQL `&&` operator) is not possible via plain SQL.
+Instead, it requires adding additional C++ code. To do this, create an [extension]({% link docs/archive/1.0/extensions/overview.md %}).
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/create_view.md b/docs/archive/1.0/sql/statements/create_view.md
new file mode 100644
index 00000000000..3313aba78b3
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/create_view.md
@@ -0,0 +1,43 @@
+---
+layout: docu
+railroad: statements/createview.js
+title: CREATE VIEW Statement
+---
+
+The `CREATE VIEW` statement defines a new view in the catalog.
+
+## Examples
+
+Create a simple view:
+
+```sql
+CREATE VIEW v1 AS SELECT * FROM tbl;
+```
+
+Create a view or replace it if a view with that name already exists:
+
+```sql
+CREATE OR REPLACE VIEW v1 AS SELECT 42;
+```
+
+Create a view and replace the column names:
+
+```sql
+CREATE VIEW v1(a) AS SELECT 42;
+```
+
+The SQL query behind an existing view can be read using the [`duckdb_views()` function]({% link docs/archive/1.0/sql/meta/duckdb_table_functions.md %}#duckdb_views) like this:
+
+```sql
+SELECT sql FROM duckdb_views() WHERE view_name = 'v1';
+```
+
+## Syntax
+
+
+
+`CREATE VIEW` defines a view of a query. The view is not physically materialized. Instead, the query is run every time the view is referenced in a query.
+
+`CREATE OR REPLACE VIEW` is similar, but if a view of the same name already exists, it is replaced.
+
+If a schema name is given then the view is created in the specified schema. Otherwise, it is created in the current schema. Temporary views exist in a special schema, so a schema name cannot be given when creating a temporary view. The name of the view must be distinct from the name of any other view or table in the same schema.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/delete.md b/docs/archive/1.0/sql/statements/delete.md
new file mode 100644
index 00000000000..27d7c40781a
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/delete.md
@@ -0,0 +1,41 @@
+---
+layout: docu
+railroad: statements/delete.js
+title: DELETE Statement
+---
+
+The `DELETE` statement removes rows from the table identified by the table-name.
+
+## Examples
+
+Remove the rows matching the condition `i = 2` from the database:
+
+```sql
+DELETE FROM tbl WHERE i = 2;
+```
+
+Delete all rows in the table `tbl`:
+
+```sql
+DELETE FROM tbl;
+```
+
+The `TRUNCATE` statement removes all rows from a table, acting as an alias for `DELETE FROM` without a `WHERE` clause:
+
+```sql
+TRUNCATE tbl;
+```
+
+## Syntax
+
+
+
+The `DELETE` statement removes rows from the table identified by the table-name.
+
+If the `WHERE` clause is not present, all records in the table are deleted. If a `WHERE` clause is supplied, then only those rows for which the `WHERE` clause results in true are deleted. Rows for which the expression is false or NULL are retained.
+
+The `USING` clause allows deleting based on the content of other tables or subqueries.
+
+## Limitations on Reclaiming Memory and Disk Space
+
+Running `DELETE` does not mean space is reclaimed. In general, rows are only marked as deleted. DuckDB reclaims space upon [performing a `CHECKPOINT`]({% link docs/archive/1.0/sql/statements/checkpoint.md %}). [`VACUUM`]({% link docs/archive/1.0/sql/statements/vacuum.md %}) currently does not reclaim space.
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/describe.md b/docs/archive/1.0/sql/statements/describe.md
new file mode 100644
index 00000000000..542b502441b
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/describe.md
@@ -0,0 +1,26 @@
+---
+layout: docu
+title: DESCRIBE Statement
+---
+
+The `DESCRIBE` statement shows the schema of a table, view or query.
+
+## Usage
+
+```sql
+DESCRIBE tbl;
+```
+
+In order to summarize a query, prepend `DESCRIBE` to a query.
+
+```sql
+DESCRIBE SELECT * FROM tbl;
+```
+
+## Alias
+
+The `SHOW` statement is an alias for `DESCRIBE`.
+
+## See Also
+
+For more examples, see the [guide on `DESCRIBE`]({% link docs/archive/1.0/guides/meta/describe.md %}).
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/drop.md b/docs/archive/1.0/sql/statements/drop.md
new file mode 100644
index 00000000000..8d960e85360
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/drop.md
@@ -0,0 +1,136 @@
+---
+layout: docu
+railroad: statements/drop.js
+title: DROP Statement
+---
+
+The `DROP` statement removes a catalog entry added previously with the `CREATE` command.
+
+## Examples
+
+Delete the table with the name `tbl`:
+
+```sql
+DROP TABLE tbl;
+```
+
+Drop the view with the name `v1`; do not throw an error if the view does not exist:
+
+```sql
+DROP VIEW IF EXISTS v1;
+```
+
+Drop function `fn`:
+
+```sql
+DROP FUNCTION fn;
+```
+
+Drop index `idx`:
+
+```sql
+DROP INDEX idx;
+```
+
+Drop schema `sch`:
+
+```sql
+DROP SCHEMA sch;
+```
+
+Drop sequence `seq`:
+
+```sql
+DROP SEQUENCE seq;
+```
+
+Drop macro `mcr`:
+
+```sql
+DROP MACRO mcr;
+```
+
+Drop macro table `mt`:
+
+```sql
+DROP MACRO TABLE mt;
+```
+
+Drop type `typ`:
+
+```sql
+DROP TYPE typ;
+```
+
+## Syntax
+
+
+
+## Dependencies of Dropped Objects
+
+DuckDB performs limited dependency tracking for some object types.
+By default or if the `RESTRICT` clause is provided, the entry will not be dropped if there are any other objects that depend on it.
+If the `CASCADE` clause is provided then all the objects that are dependent on the object will be dropped as well.
+
+```sql
+CREATE SCHEMA myschema;
+CREATE TABLE myschema.t1 (i INTEGER);
+DROP SCHEMA myschema;
+```
+
+```console
+Dependency Error: Cannot drop entry `myschema` because there are entries that depend on it.
+Use DROP...CASCADE to drop all dependents.
+```
+
+The `CASCADE` modifier drops both myschema and `myschema.t1`:
+
+```sql
+CREATE SCHEMA myschema;
+CREATE TABLE myschema.t1 (i INTEGER);
+DROP SCHEMA myschema CASCADE;
+```
+
+The following dependencies are tracked and thus will raise an error if the user tries to drop the depending object without the `CASCADE` modifier.
+
+| Depending object type | Dependant object type |
+|--|--|
+| `SCHEMA` | `FUNCTION` |
+| `SCHEMA` | `INDEX` |
+| `SCHEMA` | `MACRO TABLE` |
+| `SCHEMA` | `MACRO` |
+| `SCHEMA` | `SCHEMA` |
+| `SCHEMA` | `SEQUENCE` |
+| `SCHEMA` | `TABLE` |
+| `SCHEMA` | `TYPE` |
+| `SCHEMA` | `VIEW` |
+| `TABLE` | `INDEX` |
+
+## Limitations
+
+### Dependencies on Views
+
+Currently, dependencies are not tracked for views. For example, if a view is created that references a table and the table is dropped, then the view will be in an invalid state:
+
+```sql
+CREATE TABLE tbl (i INTEGER);
+CREATE VIEW v AS
+ SELECT i FROM tbl;
+DROP TABLE tbl RESTRICT;
+SELECT * FROM v;
+```
+
+```console
+Catalog Error: Table with name tbl does not exist!
+```
+
+## Limitations on Reclaiming Disk Space
+
+Running `DROP TABLE` should free the memory used by the table, but not always disk space.
+Even if disk space does not decrease, the free blocks will be marked as `free`.
+For example, if we have a 2 GB file and we drop a 1 GB table, the file might still be 2 GB, but it should have 1 GB of free blocks in it.
+To check this, use the following `PRAGMA` and check the number of `free_blocks` in the output:
+
+```sql
+PRAGMA database_size;
+```
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/export.md b/docs/archive/1.0/sql/statements/export.md
new file mode 100644
index 00000000000..8a291d4d631
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/export.md
@@ -0,0 +1,79 @@
+---
+layout: docu
+railroad: statements/export.js
+title: EXPORT/IMPORT DATABASE Statements
+---
+
+The `EXPORT DATABASE` command allows you to export the contents of the database to a specific directory. The `IMPORT DATABASE` command allows you to then read the contents again.
+
+## Examples
+
+Export the database to the target directory 'target_directory' as CSV files:
+
+```sql
+EXPORT DATABASE 'target_directory';
+```
+
+Export to directory 'target_directory', using the given options for the CSV serialization:
+
+```sql
+EXPORT DATABASE 'target_directory' (FORMAT CSV, DELIMITER '|');
+```
+
+Export to directory 'target_directory', tables serialized as Parquet:
+
+```sql
+EXPORT DATABASE 'target_directory' (FORMAT PARQUET);
+```
+
+Export to directory 'target_directory', tables serialized as Parquet, compressed with ZSTD, with a row_group_size of 100,000:
+
+```sql
+EXPORT DATABASE 'target_directory' (
+ FORMAT PARQUET,
+ COMPRESSION ZSTD,
+ ROW_GROUP_SIZE 100_000
+);
+```
+
+Reload the database again:
+
+```sql
+IMPORT DATABASE 'source_directory';
+```
+
+Alternatively, use a `PRAGMA`:
+
+```sql
+PRAGMA import_database('source_directory');
+```
+
+For details regarding the writing of Parquet files, see the [Parquet Files page in the Data Import section]({% link docs/archive/1.0/data/parquet/overview.md %}#writing-to-parquet-files) and the [`COPY` Statement page]({% link docs/archive/1.0/sql/statements/copy.md %}).
+
+## `EXPORT DATABASE`
+
+The `EXPORT DATABASE` command exports the full contents of the database – including schema information, tables, views and sequences – to a specific directory that can then be loaded again. The created directory will be structured as follows:
+
+```text
+target_directory/schema.sql
+target_directory/load.sql
+target_directory/t_1.csv
+...
+target_directory/t_n.csv
+```
+
+The `schema.sql` file contains the schema statements that are found in the database. It contains any `CREATE SCHEMA`, `CREATE TABLE`, `CREATE VIEW` and `CREATE SEQUENCE` commands that are necessary to re-construct the database.
+
+The `load.sql` file contains a set of `COPY` statements that can be used to read the data from the CSV files again. The file contains a single `COPY` statement for every table found in the schema.
+
+### Syntax
+
+
+
+## `IMPORT DATABASE`
+
+The database can be reloaded by using the `IMPORT DATABASE` command again, or manually by running `schema.sql` followed by `load.sql` to re-load the data.
+
+### Syntax
+
+
\ No newline at end of file
diff --git a/docs/archive/1.0/sql/statements/insert.md b/docs/archive/1.0/sql/statements/insert.md
new file mode 100644
index 00000000000..3971bb754fc
--- /dev/null
+++ b/docs/archive/1.0/sql/statements/insert.md
@@ -0,0 +1,429 @@
+---
+layout: docu
+railroad: statements/insert.js
+title: INSERT Statement
+---
+
+The `INSERT` statement inserts new data into a table.
+
+### Examples
+
+Insert the values 1, 2, 3 into `tbl`:
+
+```sql
+INSERT INTO tbl
+ VALUES (1), (2), (3);
+```
+
+Insert the result of a query into a table:
+
+```sql
+INSERT INTO tbl
+ SELECT * FROM other_tbl;
+```
+
+Insert values into the `i` column, inserting the default value into other columns:
+
+```sql
+INSERT INTO tbl (i)
+ VALUES (1), (2), (3);
+```
+
+Explicitly insert the default value into a column:
+
+```sql
+INSERT INTO tbl (i)
+ VALUES (1), (DEFAULT), (3);
+```
+
+Assuming `tbl` has a primary key/unique constraint, do nothing on conflict:
+
+```sql
+INSERT OR IGNORE INTO tbl (i)
+ VALUES (1);
+```
+
+Or update the table with the new values instead:
+
+```sql
+INSERT OR REPLACE INTO tbl (i)
+ VALUES (1);
+```
+
+### Syntax
+
+
+
+`INSERT INTO` inserts new rows into a table. One can insert one or more rows specified by value expressions, or zero or more rows resulting from a query.
+
+## Insert Column Order
+
+It's possible to provide an optional insert column order, this can either be `BY POSITION` (the default) or `BY NAME`.
+Each column not present in the explicit or implicit column list will be filled with a default value, either its declared default value or `NULL` if there is none.
+
+If the expression for any column is not of the correct data type, automatic type conversion will be attempted.
+
+### `INSERT INTO ... [BY POSITION]`
+
+The order that values are inserted into the columns of the table is determined by the order that the columns were declared in.
+That is, the values supplied by the `VALUES` clause or query are associated with the column list left-to-right.
+This is the default option, that can be explicitly specified using the `BY POSITION` option.
+For example:
+
+```sql
+CREATE TABLE tbl (a INTEGER, b INTEGER);
+INSERT INTO tbl
+ VALUES (5, 42);
+```
+
+Specifying `BY POSITION` is optional and is equivalent to the default behavior:
+
+```sql
+INSERT INTO tbl
+ BY POSITION
+ VALUES (5, 42);
+```
+
+To use a different order, column names can be provided as part of the target, for example:
+
+```sql
+CREATE TABLE tbl (a INTEGER, b INTEGER);
+INSERT INTO tbl (b, a)
+ VALUES (5, 42);
+```
+
+Adding `BY POSITION` results in the same behavior:
+
+```sql
+INSERT INTO tbl
+ BY POSITION (b, a)
+ VALUES (5, 42);
+```
+
+This will insert `5` into `b` and `42` into `a`.
+
+### `INSERT INTO ... BY NAME`
+
+Using the `BY NAME` modifier, the names of the column list of the `SELECT` statement are matched against the column names of the table to determine the order that values should be inserted into the table. This allows inserting even in cases when the order of the columns in the table differs from the order of the values in the `SELECT` statement or certain columns are missing.
+
+For example:
+
+```sql
+CREATE TABLE tbl (a INTEGER, b INTEGER);
+INSERT INTO tbl BY NAME (SELECT 42 AS b, 32 AS a);
+INSERT INTO tbl BY NAME (SELECT 22 AS b);
+SELECT * FROM tbl;
+```
+
+| a | b |
+|-----:|---:|
+| 32 | 42 |
+| NULL | 22 |
+
+It's important to note that when using `INSERT INTO ... BY NAME`, the column names specified in the `SELECT` statement must match the column names in the table. If a column name is misspelled or does not exist in the table, an error will occur. Columns that are missing from the `SELECT` statement will be filled with the default value.
+
+## `ON CONFLICT` Clause
+
+An `ON CONFLICT` clause can be used to perform a certain action on conflicts that arise from `UNIQUE` or `PRIMARY KEY` constraints.
+An example for such a conflict is shown in the following example:
+
+```sql
+CREATE TABLE tbl (i INTEGER PRIMARY KEY, j INTEGER);
+INSERT INTO tbl
+ VALUES (1, 42);
+INSERT INTO tbl
+ VALUES (1, 84);
+```
+
+This raises as an error:
+
+```console
+Constraint Error: Duplicate key "i: 1" violates primary key constraint.
+```
+
+The table will contain the row that was first inserted:
+
+```sql
+SELECT * FROM tbl;
+```
+
+| i | j |
+|--:|---:|
+| 1 | 42 |
+
+These error messages can be avoided by explicitly handling conflicts.
+DuckDB supports two such clauses: [`ON CONFLICT DO NOTHING`](#do-nothing-clause) and [`ON CONFLICT DO UPDATE SET ...`](#do-update-clause-upsert).
+
+### `DO NOTHING` Clause
+
+The `DO NOTHING` clause causes the error(s) to be ignored, and the values are not inserted or updated.
+For example:
+
+```sql
+CREATE TABLE tbl (i INTEGER PRIMARY KEY, j INTEGER);
+INSERT INTO tbl
+ VALUES (1, 42);
+INSERT INTO tbl
+ VALUES (1, 84)
+ ON CONFLICT DO NOTHING;
+```
+
+These statements finish successfully and leaves the table with the row `