Thread: A Generic Question about Generic type subscripting

A Generic Question about Generic type subscripting

From

Hannu Krosing

Date:

29 January 2018, 13:45:15

Sorry for being late to the party

I started looking at the thread about "Generic type subscripting" and am wondering,
why does it take the approach of modifying pg_type and modifying lots of internal
functions, when instead it could be defined in a much lighter and less intrusive way

as an operator, probably by reserving a dedicated operator name

CREATE OPERATOR [...] (PROCEDURE = json_object_field, LEFTARG=jsonb, RIGHTARG=text);

CREATE OPERATOR [...] (PROCEDURE = jsonb_array_element, LEFTARG=jsonb, RIGHTARG=int);

This might put more work on the writers of actual subscription operators, but if we are looking at diverse new types, it may also be, that writing operator functions is even easier than learning a full new skillset for writing "subscripting functions"

Defining "subscripting" as an operator does still require changes to how current subscripting operations are parsed, but even there I am not sure it would be more complex, as all the parser has to do is to determine that it is a subscripting operation and then delegate to the corresponding operator.

Also, there is a problem of what to do with element (or or even slice) assignements, as there require three arguments.

I see two possibilities

1) add a third "ARG" to the CREATE OPERATOR syntax, maybe VALUEARG
2) use composite types - so for

jsonb1[int1] = jsonb2

the operator would be defined by first defining a

CREATE TYPE intkey_and_jsonvalue as (key int, value jsonb)
and then using this in
CREATE OPERATOR [...] (PROCEDURE = jsonb_set_key, LEFTARG=jsonb, RIGHTARG=intkey_and_jsonvalue)

Cheers
Hannu

Re: A Generic Question about Generic type subscripting

From

Arthur Zakirov

Date:

29 January 2018, 18:47:41

On Mon, Jan 29, 2018 at 09:45:15AM +0200, Hannu Krosing wrote:
> ...
> I see two possibilities
> 
> 1) add a third "ARG" to the CREATE OPERATOR syntax, maybe VALUEARG
> 2) use composite types - so for
> 
>     jsonb1[int1] = jsonb2
> 
> the operator would be defined by first defining a
> 
> CREATE TYPE intkey_and_jsonvalue as (key int, value jsonb)
> and then using this in
> CREATE OPERATOR [...] (PROCEDURE = jsonb_set_key, LEFTARG=jsonb,
> RIGHTARG=intkey_and_jsonvalue)

I think it will work for assignments. But what about fetching. For
example we have:

CREATE TYPE intkey_and_jsonvalue as (key int, value jsonb);
CREATE TYPE intkey_and_textvalue as (key int, value text);

What should return the next query?

select jsonb1[int1];

-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

Re: A Generic Question about Generic type subscripting

From

Tom Lane

Date:

29 January 2018, 21:42:29

Hannu Krosing <hannu.krosing@2ndquadrant.com> writes:
> I started looking at the thread about "Generic type subscripting" and am
> wondering, why does it take the approach of modifying pg_type and
> modifying lots of internal functions, when instead it could be defined
> in a much lighter and less intrusive way as an operator, probably by
> reserving a dedicated operator name

It's pretty hard to see how that would extend to allowing extensions to
support either array slices ("arr[lo:hi]") or multi-dimensional arrays.
Or at least, by the time you get done with allowing those cases, plus
assignments to them, it's not so lightweight anymore.

You could make the argument that it's okay to blow all those options off
and say that extension types only get to define the simplest form of
one-subscript subscripting.  But this patch has higher ambition than
that, and I think that's good.

            regards, tom lane