On Thu, Jan 11, 2018 at 1:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think you missed the point. The question is whether the existence of a
> subscripting function means that we need to treat the subscriptable type
> as physically containing the subscript result type. For example, if the
> subscript result type is composite, do we need to do something about a
> column of the subscriptable type when somebody does an ALTER TYPE
> ... ALTER ATTRIBUTE TYPE on the result type? The dependency mechanism
> doesn't have enough information to answer that. It's fairly easy to
> imagine cases where it wouldn't be true --- for instance, if you had
> a subscripting conversion from JSONB to my_composite_type, changing
> my_composite_type would likely change the set of JSONB values for which
> the subscripting function would succeed, but it wouldn't create a need
> to physically rewrite any JSONB columns.
I don't think I missed the point at all -- this is the exact same set
of issues that arise with respect to functions. Indeed, I gave an
example of a function that needs to be updated if a column of the
input type is altered. In the case of functions, we've decided that
it's not our problem. If the user updates the composite type and
fails to update the function definitions as needed, things might
break, so they should do that. If they don't, it's not our bug.
> After further thought, I think I'm prepared to say (for the moment) that
> only true arrays need be deemed to be containers in this sense. If you
> make a subscripting function for anything else, we'll treat it as just a
> function that happens to yield the result type but doesn't imply that that
> is what is physically stored. Perhaps at some point that will need to
> change, but I'm failing to think of near-term use cases where it would be
> important to have such a property.
In other words, we're vigorously agreeing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
