Re: [PATCH] Generic type subscription

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 23, 2017 at 2:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Can we arrange to do that differently? I'd prefer something in which the
>> argument and result types are visibly connected to the actual datatypes
>> at hand, for instance
>> array_subscript(anyarray, internal) returns anyelement
>> array_assign(anyarray, internal, anyelement) returns anyarray

> What about having no internal arguments here at all? Like if you want
> to support foo[4] define a subscript function that takes (mytype, int)
> and returns whatever. You might have to allow for multiple
> subscripting functions with different argument types for this to
> really work, though.

Yeah, the problem is if you're trying to support the full generality
of the array slice syntax, it gets kind of painful to shoehorn that
into simple SQL types. Consider array[1][2:3][4:] or something like
that. We could say that extensions only have access to the basic
non-slice notation, but I'm sure someone would be unhappy with that
--- and even then, you don't really want to define six functions to
deal with six possible numbers of subscripts.

Another issue is that, if someone is trying to use this facility to define
array semantics that are less screwball than what Berkeley bequeathed us,
they might not be happy with the idea that a single function
"array_subscript(anyarray, internal) returns anyelement" is what
determines the result type of a subscripting operation. It might be for
example that you need to look at the subscripted object, as well as the
number of subscripts, before you know whether the result is an element or
a lower-dimension array. So I'd really prefer that the functionality
involve a parser callout, and that would certainly need "internal"
argument(s).

Given that it's a parser callout, what the signatures of the runtime
function(s) are is really not our problem; the callout can construct
any darn expression tree it pleases. There would only be some subset
of that space that ruleutils.c would know how to print as a subscripting
construct, but many people might be happy with the results reverse-listing
as a regular function or operator call.

regards, tom lane