On Tue, Dec 11, 2012 at 12:59 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> For every developer who says "wow, that mysql query just worked without
> modification" there is another one who says "oh, I forgot to test with
> option XYZ... postgres is too complex to support, I'm going to drop it
> from the list of supported databases".
Perhaps so. That's why my first choice is still to just fix this
problem across the board. I think there is probably more than one way
of doing that that is technically safe, and I currently believe that
my patch is one of those. However, it seems that more people than not
find the extra casts that PostgreSQL forces programmers to use to be a
feature, not a bug. According to Tom, to allow people to call a
non-overloaded function without casts will "completely destroy the
type system"; Peter Eisentraut was aghast at the idea of allowing
someone to pass a non-text first argument to lpad without an explicit
cast. I recognize that not everyone's going to agree on these things
but I find those attitudes shockingly arrogant. We have regular
evidence that users are coming to PostgreSQL and then abandoning it
because these kinds of things don't work, and we know that numerous
other popular and well-respected systems allow these sorts of things
to Just Work. It is one thing to insist on casts when there is an
ambiguity about which of several overloaded functions a user intended
to call - but when there's only one, it's just masterminding. In more
than ten years of working with PostgreSQL, I've never encountered
where the restriction at issue here prevented a bug. It's only
annoyed me and broken my application code (when moving from PostgreSQL
8.2 to PostgreSQL 8.3, never mind any other database!). There is
ample evidence that I'm not the only one, but I think we have a clear
consensus to continue ignoring the problem, or at least the solutions.
I don't think there's much point in carrying this patch over to the
next CommitFest; I'll mark it as Rejected.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company