On 01/29/2014 12:07 AM, Craig Ringer wrote:
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.
And therein lies the problem, in the pursuit of simplicity, application
developers have embraced complicated stacks. A change at any point in
the above stack has the potential to unravel the whole system. So it is
not obvious to me that 'fixing' one end of the stack is going to solve
the problem as a whole.
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?
See above, I do not think that is possible.
--
Adrian Klaver
adrian.klaver@xxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
