Re: [HACKERS] [PATCH] Generic type subscripting
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] [PATCH] Generic type subscripting |
Дата | |
Msg-id | 12567.1515698452@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Generic type subscripting (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] [PATCH] Generic type subscripting
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: