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