On Wed, Jan 29, 2014 at 03:05:23PM +0800, Craig Ringer wrote:
> This is a painful issue for a significant group
Yes.
> 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.
Also yes. This is important. The _whole point_ of ORMs is that
they're hiding the underlying details of the database implementation;
in practice, this turns out to be lowest common denominator where
"lowest" is pretty low. "Database-agnostic" code is, by definition,
not going to use database-specific features.
The idea that you can have a database-agnostic ORM that can use all
the clever features of the underlying database system is just
confused. You can't have this both ways, and other strongly-typed
database systems don't do a whole lot better with this (often, you
will discover that the automatically-generated schemas these ORMs
produce use type text everywhere, for exactly this reason). People
who insist that this ought to be possible in the general case are
saying, "I want a pony."
What you might do, however, is generate a bunch of CREATE CAST
statements for the implicit casts from text you want. This is
dangerous for all the reasons Tom noted, but it might be actually good
enough for the ORM cases you're worried about. If you think that,
maybe the right answer is to start up a project like
"ORM-cast-footgun" or whatever and create the relevant casts in a
generalized way.
> 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.
That's a fun false dichotomy, but Postgres is a general purpose tool
and therefore needs to ship by default with the safest general purpose
behaviour. Unlike many other systems, however, Postgres actually
gives you the power to adjust its behaviour according to your use
case, and there's no reason not to use that when appropriate.
Best regards,
A
--
Andrew Sullivan
ajs@crankycanuck.ca