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