Craig Ringer <craig@2ndquadrant.com> writes:
> On 01/29/2014 02:01 PM, Tom Lane wrote:
>> 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?
The problem with an implicit cast is that it might or might not happen,
either way being contrary to the user's nearly-subconscious expectation.
If the cast isn't applied, then validation that might have been done
by the destination type is moot.
In the cases where current policy deems an implicit cast to be safe,
it doesn't matter a whole lot because the semantics of most operators
are about the same for either the source or destination type; even
if the user doesn't understand exactly which operator will be used for
"2 < 2.5", he's unlikely to be surprised by the results. This happy
state of affairs doesn't hold for casts between text and some random
other type though.
Or in short, the risk factor here is that the user might write his
query assuming that an implicit cast from text would get applied,
but it doesn't and the operation proceeds using textual semantics.
This'd affect a different set of queries from the cases with
implicit casts to text, but the outcome is rather similar.
Prior to 7.3, Postgres did actually allow a bunch of implicit
coercions from text, and they caused their share of problems.
> 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.
Well, that's the end result of being "database agnostic", when it's
defined in the terms these libraries have traditionally used, which
really is "we're going to pick a tiny subset of SQL and code strictly
to that".
I think the burden is on them to figure out how their abstractions
should be generalized. What you're suggesting is that we poke a
big hole in our type system to let them avoid doing the first round
of necessary fixes --- but most likely, there are still things they'd
need to change even if we did so, leaving us with a hole in our type
system and not much to show for it.
> 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.
Uh, no, it's created by ORMs that haven't heard of type extensibility.
The reason they don't have this problem with other databases is exactly
because those other databases don't have type extensibility.
regards, tom lane
