What happens
A destination with an extra column is rejected on column count:
CREATE TABLE src (id Int64, a Int32)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/shard0/src', '{replica}')
ORDER BY tuple() PARTITION BY a;
CREATE TABLE dst (id Int64, a Int32, b Int32)
ENGINE = S3(..., format='Parquet', partition_strategy='hive') PARTITION BY a;
INSERT INTO src VALUES (1, 42);
ALTER TABLE src EXPORT PARTITION ID '42' TO TABLE dst;
-- Code: 20. Number of columns doesn't match (source: 2 and result: 3).
That one seems right to me.
But giving the extra column a DEFAULT changes nothing:
CREATE TABLE dst (id Int64, a Int32, b Int32 DEFAULT 42)
ENGINE = S3(..., format='Parquet', partition_strategy='hive') PARTITION BY a;
ALTER TABLE src EXPORT PARTITION ID '42' TO TABLE dst;
-- Code: 20. Number of columns doesn't match (source: 2 and result: 3).
Same error, same counts - the DEFAULT is not taken into account.
What I'd expect
I'd expect the second case to succeed, with b filled from its default:
SELECT id, a, b FROM dst;
-- 1 42 42
which is what
INSERT INTO dst (id, a)
SELECT id, a
FROM src;
would produce.
A DEFAULT column is exactly the case where the destination can supply the value itself, so requiring the source to provide it seems off.
Is the current behaviour intended? There's no data-loss risk either way since it's a loud rejection.
What happens
A destination with an extra column is rejected on column count:
That one seems right to me.
But giving the extra column a
DEFAULTchanges nothing:Same error, same counts - the
DEFAULTis not taken into account.What I'd expect
I'd expect the second case to succeed, with
bfilled from its default:which is what
would produce.
A
DEFAULTcolumn is exactly the case where the destination can supply the value itself, so requiring the source to provide it seems off.Is the current behaviour intended? There's no data-loss risk either way since it's a loud rejection.