On Wed, Nov 21, 2012 at 5:10 PM, Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
