Re: [HACKERS] [PATCH] Generic type subscripting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [PATCH] Generic type subscripting
Date
Msg-id 12567.1515698452@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Generic type subscripting  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] [PATCH] Generic type subscripting
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Next
From: Alvaro Herrera
Date:
Subject: Re: CUBE seems a bit confused about ORDER BY