Hi Tom!
On 8 February 2013 15:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> AFAIK this is just business as usual with JDBC: setString() implies that
> the parameter is of a string type. It'll fall over if the type actually
> required is anything but a string. (I'm no Java expert, but I seem to
> recall that using setObject instead is the standard workaround.)
>
> Enums are not suffering any special hardship here, and I'd be against
> weakening the type system to give them a special pass.
Yes, you can use setObject(1, "enumval", Types.OTHER). I was hoping
that setString might work, as mapping java enum values to strings in
the database is a very common ORM technique that is built into
basically all major ORMs including all that support the JPA standard,
and it leads to people using varchars instead of typesafe enums in
their dbs. If setString worked, people could migrate their schemas to
the typesafe versions without touching any code. Using setObject
people need to write a custom converter in most of those systems, and
configure its use for each enum that they have. This then also makes
swapping database backends difficult (for people who care about that
sort of thing), since the jdbc calls are now different for postgresql
vs anything else.
Anyway, if there's no nice way to do it in the backend without adding
implicit casts, and you're not happy with the costs of that as a
solution, I guess that's that. I guess I was hoping that a text value
parameter to a prepared statement could be treated as input when the
type didn't match, but I don't know if that's feasible, and I guess
it's probably opening the door to confusing error messages when
someone provides the wrong type accidentally.
Thanks
Tom
