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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
