Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 11, 2018 at 1:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
There are two critical differences --- that's one, and the other is
that there are SQL-level ways to fix the problem, ie change the function
text with CREATE OR REPLACE FUNCTION. We don't have a SQL command that
says "now go update the representation of table T column C".
But I think we've probably beaten this topic to death ...
regards, tom lane