Refactor POST_CREATE and POST_EXPRESSION properties

[treysp]

Convert Create args to properties in POST_CREATE location:

• set
• multiset
• global_temporary
• volatile
• temporary
• transient
• external
• materialized

Convert Create args to properties in POST_EXPRESSION location:

• data
• statistics
• no_primary_index

Add preserve_rows property in POST_EXPRESSION location for ON COMMIT PRESERVE ROWS #1205

Make SetProperty unsupported in Snowflake (Teradata "CREATE MULTISET TABLE a" -> Snowflake "CREATE TABLE a") #1205

[treysp]

The Teradata syntax "CREATE VOLATILE TABLE" isn't supported in Snowflake, and the "obvious" way to handle is to set the volatility property to unsupported in Snowflake. However, the volatility property is also mapped to keyword IMMUTABLE (which snowflake does support).

You can see in

sqlglot/sqlglot/parser.py

Line 536 in b143418

"DETERMINISTIC": lambda self: self.expression(

that the VolatilityProperty is capturing all of deterministic, immutable, stable, and volatile.

Not sure the best way to handle this. We can pull them into separate properties, but that will complicate transpiling one of those words to another.

[treysp]

I also see that the CREATE_TRANSIENT flag was essentially playing the role of UNSUPPORTED properties for the Transient property in POST_CREATE location.

I don't see this being used in any other dialects, so I'll remove it when responding to review comments.

sqlglot/sqlglot/generator.py

Line 90 in b143418

# Whether 'CREATE ... TRANSIENT ... TABLE' is allowed

sqlglot/sqlglot/dialects/snowflake.py

Line 218 in b143418

CREATE_TRANSIENT = True

[georgesittas]

The Teradata syntax "CREATE VOLATILE TABLE" isn't supported in Snowflake, and the "obvious" way to handle is to set the volatility property to unsupported in Snowflake. However, the volatility property is also mapped to keyword IMMUTABLE (which snowflake does support).

You can see in

sqlglot/sqlglot/parser.py

Line 536 in b143418

"DETERMINISTIC": lambda self: self.expression(

that the VolatilityProperty is capturing all of deterministic, immutable, stable, and volatile.

Not sure the best way to handle this. We can pull them into separate properties, but that will complicate transpiling one of those words to another.

Maybe you can also check if the string captured in exp.VolatilityProperty is legal in Snowflake. So, for instance, you'd only allow IMMUTABLE if that's the only valid one.

[treysp]

The Teradata syntax "CREATE VOLATILE TABLE" isn't supported in Snowflake, and the "obvious" way to handle is to set the volatility property to unsupported in Snowflake. However, the volatility property is also mapped to keyword IMMUTABLE (which snowflake does support).
You can see in

sqlglot/sqlglot/parser.py

Line 536 in b143418

"DETERMINISTIC": lambda self: self.expression(

that the VolatilityProperty is capturing all of deterministic, immutable, stable, and volatile.
Not sure the best way to handle this. We can pull them into separate properties, but that will complicate transpiling one of those words to another.

Maybe you can also check if the string captured in exp.VolatilityProperty is legal in Snowflake. So, for instance, you'd only allow IMMUTABLE if that's the only valid one.

That makes sense, but I don't think it would work if multiple volatility words are used for different things in the same dialect and/or word usages aren't aligned across dialects. (So in one dialect VOLATILE means X and IMMUTABLE means Y, but in another dialect VOLATILE means Y and IMMUTABLE means X.)

I think resolving this will probably require reviewing volatility-related words across the dialects. I'm happy to do that, but it will take me a few days to get to it.

[tobymao]

delete this