On 9/5/14 9:04 AM, Craig Ringer wrote:
> It's easy to object to this on type-purist grounds, but from a pragmatic
> real-users point of view what we currently do is outright painful, and
> unless we can go and fix every language binding, every query generator,
> every ORM, etc to handle things just how PostgreSQL expects, some
> compromise may be warranted.
>
> It's easy to dismiss the problem by saying "pass 'unknown' typed
> literals via your language binding". That even works if you're willing
> to jump through some hoops and are using raw JDBC. Good luck doing that
> via EclipseLink, Hibernate, ActiveRecord, SQLAlchemy, MyBatis, Django
> ORM, or any of the things people use to talk to PostgreSQL on a day to
> day basis though.
>
> Right now it's really painful to use some of PostgreSQL's best features
> without hacking around the type system by manually creating implicit
> casts. Another option is to work around it by completely removing the
> benefit of the strict casting even when it's obviously right (e.g.
> refusing to cast text to date) with the JDBC connection parameter
> stringtype=unknown .
>
> I'd like to get rid of the need for users to add possibly-buggy custom
> casts or bypass type checking of text types, by relaxing the casts where
> appropriate.
I really don't like the idea of relaxing casts. And I really object to
the notion of casting from test to date being "obviously right".
The problem here seems to be only related to mistyped parameters. Can
we contain the damage to that part only somehow? Or make this optional
(defaulting to off, I hope)?
.marko