Re: [hibernate-dev] SQM and cast targets

Yes, ultimately these need to resolve to SqlTypeDescriptor. So perhaps we allow both. What I just want to get out of is the open-ended-ness. Non-determinism is bad. E.g., like what you just mentioned... how should the parser understand that "TEXT" `cast(x as TEXT)` is a database type name versus Java class name versus something else? Structurally we cannot - one String is syntactically the same as any other String. So do we just accept some policy of "well if we don't understand it we'll just pass it through to the database"? To me that's just a cop-out. Not to mention that it invariably leaves the door open to non-portability. If instead we limited this to just Java types (JavaTypeDescriptorRegistry keys) and JDBC type codes (SqlTypeDescriptorRegistry keys) we can fully support this in a portable manner. Now that does lead to a question for databases which make the silly decision (looking at you pgsql) to map multiple types to the same JDBC type code. As much as possible I think we ought to not be relying on the database to validate these kinds of things. An error from the database is going to be much less descriptive as to what exactly is wrong compared to a validation done by Hibernate. Not sure the correct answer, just some thoughts. An option is to allow 3 types of cast targets: 1. Java type name we can resolve against the JavaTypeDescriptorRegistry 2. A JDBC type (either by code or name) we can resolve against the SqlTypeDescriptorRegistry 3. Any other text we can resolve against the Dialect as a "valid SQL type" I'm kind of leery of (3), but if everyone else agrees it is important to allow that non-portability then I will consider it. And keep in mind that this is really only needed for databases like pgsql to handle the multiple types it maps to a single JDBC type code... all other cases can (and should) be handled by (1) and (2). On Mon, May 29, 2017 at 10:36 AM Christian Beikov < christian.beikov(a)gmail.com&gt; wrote: