On Thu, Jan 11, 2018 at 1:37 PM, Tom Lane <tgl@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
