On Wed, Nov 21, 2012 at 5:10 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> Because a strongly-typed system should not cast numbers to strings
> implicitly. Does the equivalent of the lpad case work in any other
> strongly-typed programming language?
Does any other strongly-typed programming language distinguish between
explicit, assignment, and implicit casting the way that PostgreSQL
does? In order for the equivalent of the lpad case to exist in some
other programming language, I think they'd need to make that
distinction, and AFAICT no one does that. The only other programming
language I know of in which you can define what it means to cast
between two data types is C++, and it's not generally considered one
of that languages better features. AFAICT, they have implicit casts
and explicit casts, but nothing intermediate. There are dynamic_cast,
static_cast, and reinterpret_cast as well, but those trade-off
efficiency for the possibility of a segmentation fault, and have
nothing to do with the context in which the cast can be applied
automatically.
So I think the answer to your question is probably no, purely on the
grounds that we have set a new world record for byzantine casting
systems. A more fair comparison might be to look at what other SQL
systems allow. Oracle, MySQL, and SQL Server all permit implicit
casting between integer and text, and a call to LPAD with an integer
first argument works just fine in both Oracle and MySQL. It doesn't
work in SQL server, but that's only because SQL server doesn't have it
as a built-in function. FWICT, there's no general problem with
passing an integer to a function that expects varchar in any
mainstream RDBMS other than PostgreSQL.
>> 2. What's your counter-proposal?
>
> Leave things as they are.
I'd be fine with that if we had a system that allows users to pick the
behavior that they want in their particular environment, but in fact
our existing system is extremely inflexible. If you start adding
additional implicit casts to the system, you get failures trying to
invoke commonly-used system functions, because we've got overloaded
versions of them precisely to work around the fact that our casting
rules are more restrictive than real-world users want them to be. If
that's not prima facie evidence that the system doesn't work well in
the real world, I'm not sure what would qualify.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
