On Thu, Jan 11, 2018 at 1:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I don't think I missed the point at all -- this is the exact same set >> of issues that arise with respect to functions. Indeed, I gave an >> example of a function that needs to be updated if a column of the >> input type is altered. In the case of functions, we've decided that >> it's not our problem. > > Right, but in the case of stored arrays, we've decided that it *is* > our problem (as indeed it must be, because the user has no tools with > which they could fix a representation change for stored data). The > question is to what extent that need would propagate to pseudo array > types.
I think I view the rationale a bit differently. Let's say that a user defines a composite type as (a int, b text) and uses that composite type as a column type. Then, somebody tries to change column a to have type text, and suppose we don't throw an error but simply permit the operation. If the user now tries to select from the offending column, the server will very likely crash. In contrast, in the case where the user has defined an SQL function that selects $1.a and returns it as an int, they will get a runtime error when they try to use the function. In my mind, that is the critical difference. An operation that can cause the server to crash or emit internal errors must be prohibited, whereas an operation that might cause stuff to fail with suitable error messages in the future can be allowed. In other words, the problem isn't that the user has no tools to fix the problem; it's that, with certain exceptions like superusers indulging in random catalog-hackery, unprivileged users shouldn't be allowed to break the world. You might point out that the chances of break-the-world behavior for type subscripting are pretty high, since we're slinging around arguments of type internal. But C functions are always an exception to the notion that we'll trap and report errors. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
