From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Andres Freund <andres@anarazel.de>, Dmitry Dolgov <9erthalion6@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>,
        Arthur Zakirov <a.zakirov@postgrespro.ru>,
        Oleg Bartunov <obartunov@gmail.com>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        David Steele <david@pgmasters.net>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
In-reply-to: 
 <CA+TgmoZuU9x-7ZVEggCFngjesVO==xp8hGPkcGS5BdK793f5UA@mail.gmail.com>
References: 
 <CA+q6zcUws7270pFKgT7G0jFuLxmCaBLqPL0o4sfgfLnRBGg9gg@mail.gmail.com>
 <20171116114016.GA21162@zakirov.localdomain>
 <CA+q6zcUn+9OnuMh3Mvu=XaNpSmLGo2HrYcowgJqCDrhKifaz+A@mail.gmail.com>
 <20171119151350.GA23853@arthur.localdomain>
 <CA+q6zcXff34m4EskCiWdvc2BTx2J++w5gwSb43X0ejgg+sj9Wg@mail.gmail.com>
 <CAB7nPqSQFonLWsVr1OuDDd7NBHOBMNiHdvRwhxpkNV2W9-QUgg@mail.gmail.com>
 <CA+q6zcW52cJ-T3xrGm5BJ8ET6bcc0n3OYhM_oA9AQxAMZR2Otg@mail.gmail.com>
 <CA+q6zcX7W56i-k-_KK51ZQA3GZZKsFx0KzGAGm2rtC8M7948kQ@mail.gmail.com>
 <8809.1515031526@sss.pgh.pa.us>
 <CA+q6zcVuBkjWWYixH8ERPkaQiA9daAYmHTSRn=jn_Ajrzp1=Ug@mail.gmail.com>
 <20180108232959.s2ipp7tjcvlaixcs@alap3.anarazel.de>
 <846.1515629363@sss.pgh.pa.us>
 <CA+TgmoZ+eZ+RYUCr5cyoBzwXMDLZWTO264PGE81bNwwe5_WNGw@mail.gmail.com>
 <10021.1515694533@sss.pgh.pa.us>
 <CA+Tgmobvw+V3yG4LH3VzmR=9ais8fWFgeym1kYpZbjGLDzA3ig@mail.gmail.com>
 <10983.1515695825@sss.pgh.pa.us>
 <CA+TgmoZuU9x-7ZVEggCFngjesVO==xp8hGPkcGS5BdK793f5UA@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 11 Jan 2018 14:05:15 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12566.1515698452.1@sss.pgh.pa.us>
Date: Thu, 11 Jan 2018 14:20:52 -0500
Message-ID: <12567.1515698452@sss.pgh.pa.us>
Precedence: bulk

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