On 01/29/2014 02:01 PM, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> 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'd be interested in some examples of that. It's clear that implicit
casts *to* text were unsafe, but what makes implicit casts *from* text
*to* validated types with specific structures just as bad?
How does allowing an implicit cast from 'text' to 'macaddr' create the
opportunity for an undetected error?
Or 'hstore' ?
I'm not seeing the risk here.
This is a painful issue for a significant group; you can find them on
Stack Overflow, Rails and Django and Hibernate discussion boards, Java
user groups, etc. They've been taught not to care about the DB and write
"database-agnostic" code, but they're seeing Pg features that're so
useful that they'd like to bend that and start using some Pg features.
Only to find they can't do it without throwing away everything they have.
I wish ORMs would go away sometimes too, and I recognise that there are
certain kinds of broken and stupid that it makes no sense to cater to. I
just don't think this is one of them - this problem is universal, I
can't think of an ORM that *doesn't* have it, and it's created by
PostgreSQL, not the ORMs.
I guess this comes down to whether the goal is to be like Haskell -
pure, perfect, and used by nobody for anything real - or a pragmatic
tool for real world productive use.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services