Add support for CREATE TABLE AS

[JelteF]

This adds support for queries like:

CREATE TABLE mytable AS SELECT column00 from read_csv("my_data.csv") AS (column00 int)

The table will be then be created in Postgres (not in DuckDB). The main
change that supports this is that we now start "deparsing" the parsed
Query type from Postgres to an actual query string, instead of sending
the original string that Postgres received to DuckDB.

This also accidentally fixes some differences such as the DuckDB
count(*) aggregate creating a count_star vs Postgres its count
column. So it reduces the need for #36 a bit. The reason this happens is
because it is deparsed very explicitly like count(*) AS count.

For similar reasons this also changes the behaviour of the following
query to only return the id and name columns, instead of all the
columns. It's arguable whether that's a good thing or not: it's more
verbose if you want those columns but it's also less surprising.

SELECT * FROM read_parquet(...) AS (id int, name text);

One especially surprising thing with the above query is that
if you used a column name that was not in the parquet file,
then your query would succeed, but you would not actually
get that column back in the result (only the actual columns
in the file).

[JelteF]

The previous DuckDB pushdown was actually returning the wrong results here. So the DuckDB failure that this introduces is better than the alternative imho. Because now it warns and automatically falls back to Postgres, instead of returning a wrong result.

[Tishj]

Yea I noticed that as well, the postgres catalog extension solved the same problem

[JelteF]

The SELECT in the CREATE MATERIALIZED VIEW command now also goes through DuckDB. This is a good thing imho, because that means that we can use read_csv and read_parquet in those queries too.

However, on PG16 our type mapping results in the following error:

 CREATE MATERIALIZED VIEW tv AS SELECT * FROM t WHERE a % 100 = 0;
+ERROR:  SELECT rule's target entry 2 has different type from column "b"
+DETAIL:  SELECT target entry has type text, but column has type character varying.

Surprisingly in PG17 this works just fine.

While suboptimal that we now need to use VARCHAR, I think this is an improvement overall. And probably this means that we need to improve our type mapping a bit and actually return TEXT instead of VARCHAR from queries where the original table uses TEXT.

[mkaruza]

We already check this condition in DuckdbPlannerHook if statement but this is better place to contain this check commandType == SELECT.

[JelteF]

I moved a few more checks from the DuckDBPlannerHook to IsAllowedStatement now.

[Tishj]

Thanks this sounds like a good change to me 👍

The base branch was changed.