I don't mind if you want to experiment with this approach, but I guess I'd rather not use the "good name" for something that expects SQL dialect specific DDL fragments. I'd like to keep the good name for the abstraction if we anticipate to add this.

I really think that list and hash partitioning are something that can be nicely abstracted and that specifying the partitions for these partitioning schemes is actually something that make sense for people to define in their code.
For range partitioning I am not so sure. I guess most people that use range partitioning will have some sort of tool that automates the generation of new partitions. Specifying the partitions for range partitioning in code then seems a bit unnecessary. We could maybe start out with a simple @PartitionByRange annotation that doesn't accept partitions. We would simply emit a default partition in the DDL that accepts all values. If people start using this and request this feature, we can think about adding it. Wdyt @gavinking?

My main issue is that I think the annotations you're proposing are going to end up verbose, difficult to read, and inconvenient to write, compared to just writing fragments of SQL, and that the more verbose approach doesn't actually offer any benefits in practice because the number of systems in the intersection of 1. using partitioning, 2. doing cross-db development, and 3. using schema export to create the partitioned schema, is a vanishingly tiny set.

What i'm saying is that something like what I sketched out above is more user-friendly, significantly less complicated, and also makes it easier for people to get at every last little nuance or toggle switch of what their db offers, rather that having to target some sort of lowest-common-denominator.

the number of systems in the intersection of 1. using partitioning, 2. doing cross-db development, and 3. using schema export to create the partitioned schema, is a vanishingly tiny set.

This kind of makes me think we should maybe not do it at all unless someone from the community steps up and provides us with real world needs and use cases.

What i'm saying is that something like what I sketched out above is more user-friendly, significantly less complicated, and also makes it easier for people to get at every last little nuance or toggle switch of what their db offers, rather that having to target some sort of lowest-common-denominator.

Yeah that's true. Since the @Partition column wouldn't interfere with the naming I proposed, it's fine for me if you want to take a stab at that.

@beikov
We'd like to provide our real-world use case:
There's an account table (containing accounts and balances), every day we make a snapshot into the account_snapshot table (that contains snapshot_date, account, and balance cols). That's a huge table, and we'd like to partition this table by snapshot_date column, by range (weekly). We're restricted to use hbm2ddl to create database schema.
For us, minimal feature would be the support of partitioning in hbm2ddl, creation of partions themselves would be done via native queries.

Your request is noted and I understand that it is desirable to have this, but you really shouldn't rely solely on hbm2ddl for schema management.

This has nothing to do with this discussion. Going to delete this. Go to https://hibernate.org/community/ and ask your question on the forums or chat.