Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Jan 10, 2018 at 7:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> * The complaint I had about the "container" terminology isn't just
>> terminology. Rather, there is a bunch of knowledge in the system that
>> some data types can be found embedded in other types; for one example,
>> see find_composite_type_dependencies.
> Well, if I set things up so that subscripting foo by integer returns
> bar, that doesn't seem to be much different, from the point of view of
> type dependencies, from CREATE FUNCTION some_function_name(foo,
> integer) RETURNS bar.
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. But perhaps somebody might
try to build a subscriptable type for which they did need that.
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.
This is, however, a good reason why I don't like the use of "container"
terminology in the patch. I think we want to reserve "container" for
types where physical containment is assumed.
>> * There are other identifiable array-specific behaviors that people
>> might expect a generic subscripting feature to let them into.
> Our SQL dialect is statically typed; trying to support duck-typing
> seems likely to create a lot of problems.
Agreed; that's pretty much what my point was too. I'm just trying
to be clear about how far we expect this capability to reach.
regards, tom lane
