Robert Haas <robertmh...@gmail.com> writes: > On Thu, Jan 11, 2018 at 1:37 PM, Tom Lane <t...@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