On 01/29/2014 02:36 PM, David Johnston wrote:
>
> The "correct" solution would seem to be for ORMs to "bind unknown" against
> the input but only when the supplied string is meant to be a representation
> of a PostgreSQL type as opposed to being actual string data. The ORM is free
> to provide the necessary API to distinguish between the two and the caller
> has to know then database to call the proper method (i.e., not setString if
> your data intended for anything besides a text/varchar column).
I certainly agree that that's the ideal, and it's closer to achievable
than any other fix to these sorts of systems.
A challenge I've found when approaching this from the ORM side has been
getting people to care. The sentiment has tended to be along the lines
of: No other DBMS does this or requires this, why do we have to jump
through hoops just to make PostgreSQL happy?
I'm not claiming that's a good reason for inaction.
I think there's more hope of getting ORM systems to differentiate
between "unknown-typed literal" and "concrete text-typed literal" than
actually implementing proper support for Pg's numerous useful types. Not
much more hope, but some.
Look at the example that started this thread, though. The stack is:
PostgreSQL
PgJDBC
Java JDBC API
EBean ORM
Play! Framework
and *every level* needs to have a clue about this or a way to pass the
information trough transparently.
Now think about Hibernate, Sequel ORM, Django ORM, ActiveRecord,
EclipseLink, OpenJPA, DataMapper, Entity Framework, EBean, TopLink,
iBatis/MyBatis, Doctrine, Propel, CakePHP, Zend, SQLAlchemy, ....
Wouldn't it be nice if we could find a solution to this user pain point
in one place?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
