How to approach generating Teradata CREATE TABLE "PARTITION BY" property?

[treysp]

I recently submitted #1033 and #1065 to parse Teradata's properties that come earlier in the CREATE TABLE syntax than the parser assumed. @georgesittas then refactored and cleaned things up in #1068 and #1069.

Irritatingly, Teradata's PARTITION BY property is in a third location, between the primary and secondary indexes. Parsing isn't hard, but I'm unsure how to handle the resulting exp.PartitionedByProperty in the generator.

The generator code determines where a property should be written based on which of the BEFORE_PROPERTIES, ROOT_PROPERTIES, and WITH_PROPERTIES sets it's in. Every property is assigned to exactly one of those sets.

However, once Teradata's PARTITION BY property is allowed an exp.PartitionedByProperty can go in either the WITH_PROPERTIES location or this new third location.

What's the best way to handle this?

[tobymao]

i'm not sure i fully understand the issue.

However, once Teradata's PARTITION BY property is allowed an exp.PartitionedByProperty can go in either the WITH_PROPERTIES location or this new third location.

do you want PartitionedByProperty to be in the WITH or not?

[treysp]

Sorry, that wasn't clear.

The issue is with transpilation. For identity, there's no problem since the property goes back where it came from in the parsed code.

But if we want to transpile from Teradata to something else, the generator needs to know that it should go in the WITH instead of the Teradata location. Basically, this property should be in the WITH for some dialects, elsewhere for other dialects.

[tobymao]

right. there can be some kind of mapping of properties to with, before, and index that can be overriden