Ordinal positions differ with same set of columns

[joshelser]

Saw this exactly once:

-- returns 78 to 81
call admin.run_as_app($$ SELECT COLUMN_NAME, DATA_TYPE, ORDINAL_POSITION FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'INTERNAL_REPORTING' AND TABLE_NAME = 'QUERY_HISTORY_COMPLETE_AND_DAILY' and column_name ilike '%hash%' order by ordinal_position $$);
-- returns 82 to 85
call admin.run_as_app($$ SELECT COLUMN_NAME, DATA_TYPE, ORDINAL_POSITION FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'INTERNAL_REPORTING_MV' AND TABLE_NAME = 'QUERY_HISTORY_COMPLETE_AND_DAILY'  and column_name ilike '%hash%' order by ordinal_position $$);

I don't know if this was due to something else I had done or if it's a less-than-likely situation where snowflake may skip ordinal positions.

[rymurr]

What is the effect of this?

[joshelser]

It caused an exception to be raised every time the 005_migrations.sql procedure ran because it would try to re-add the columns from internal_reporting.query_history_complete_and_daily to internal_reporting_mv.query_history_complete_and_daily, effectively breaking all future materializations (as we always try to migrate when the query history maintenance task is executed)