David, > I have no idea how this mechanism works but ISTM that the planner could, for > "anyelement", look at where the result of the function call is used and add > a cast to the function input value to match the desired result type if the > input type is "undefined".
Well, that's not how "anyelement" works, actually. And the input type for min() is not "anyelement". > I'm curious what you would consider to be a "more apropos error message" in > this situation; regardless of how difficult it would be to implement. "ERROR: unable to determine appropriate type for 'NULL'" But again, don't hold your breath, per above. > I am also curious if you can think of a better example of where this > behavior is problematic. The query for this thread is not something that I > would deem to be good SQL. Yeah, but it gets generated a lot. And per your other example, sometimes it *does* work, so developers/ORM authors start to rely on it. And then it breaks. Mostly the problematic cases are involving function parameters, where adding a new version of a function can suddently cause a call with an unadorned NULL to break, when it used to work. For example, suppose I have only one function "dingbat" dingbat( timestamptz, text, text, float ) I can easily call it with: SELECT dingbat( '2013-01-01', 'Josh', 'pgsql-hackers', NULL ) But if someone else adds a second function, possibly due to a typo with the version control system: dingbat(timestamptz, text, text, text) ... then the above SELECT call will automatically choose the second function, because NULL defaults to TEXT if unadorned. Among other things, that could make a fun exploit if people have been careless with their SECURITY DEFINER functions. A worse example is the CIText type. A couple versions ago, I attempted to force default case-insensitive comparisons for: 'val'::CITEXT = 'val'::TEXT ... which is what the user would intuitively believe would happen, instead of the case-sensitive comparison, which is what *does* happen. After a long weekend of messy bug-hunting and breaking built-in postgresql functions, I gave up. The root cause of this is that we treat "default TEXT" the same as "real TEXT" as a type. Changing that logic, though, would require a massive refactoring and debugging of PostgreSQL. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers