Tom Lane-2 wrote
> Craig Ringer <
> craig@
> > writes:
>> I just want us to allow, by default, implicit casts FROM text (not TO
>> text) using the input function for all PostgreSQL's validated
>> non-standard types (and XML due to limited deployment of SQL/XML support
>> in client drivers).
>
> Sorry, that is *just* as dangerous as implicit casts to text were.
> It would bite a different set of queries, but not any less painfully.
>
> I have about zero sympathy for ORMs that aren't willing to address
> this issue properly. Yeah, it might be less than trivial, but that
> doesn't mean that the right answer is to create semantic hazards
> on the server side.
Less dangerous since an error will eventually be thrown on non-conforming
input but we've still moved what is now a parse-time error into a runtime
error.
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'm not sure how function overloading can be solved no matter which implicit
cast procedure methodology you choose; though I haven't ponder it much. The
goal should be for the ORM to basically tell PostgreSQL "here's some data,
you deal with it. That is exactly what the "unknown" moniker is for. But if
they tell us it's a text typed value we believe them.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/PostgreSQL-specific-datatypes-very-confusing-for-beginners-who-use-wrappers-around-JDBC-tp5789352p5789429.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
