Georg Traar

> Another option would be the implementation of something like a MERGE statement, i.e. recalculate the new data in the source table and merge it into a target table: Is...

**Draft proposal following PostgreSQL beahviour** ⚠️ Feel free to edit ⚠️ No decision to implement The propose approach largely follows the [PostgreSQL implementation of materialized views](https://www.postgresql.org/docs/current/sql-creatematerializedview.html). > `CREATE MATERIALIZED VIEW` ...

> Imho we'd want to keep having this table names in sys.snapshots in sync with pg_tables and information_schema.tables , and in those we don't have " when they are need,...

> What is the reason for this deviation? In PostgreSQL: `round` and `trunc` generally returns a `double precision` without the precision parameter and a `numeric` with the precision parameter. Also...

> This would be needed for some tests in Tableau I think the only real open point is the question about the return type. Otherwise this PR is sitting ready...

I rebased and updated it. As mentioned in the comments, I believe there's no way to avoid using BigDecimal for rounding unless we're okay with deviating from PostgreSQL's behavior and...

One way to support `NUMERIC` for storage **and** query **to some extent**, would be to base it on `bigint` and only allow limited values for `precision` and `scale` `0 <...

with #731 datatypes would be handled separately from reserved keywords.

> When viewing `EXPLAIN` results they are crammed into a `max-width: 400px` cell. > > It would be great to have unbounded cells for results with a single column. If...

@DHRUV6029 Just GROUP BY ALL. Ordinal number references are already implemented.