A Generic Question about Generic type subscripting

From: Hannu Krosing <hannu(dot)krosing(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: A Generic Question about Generic type subscripting
Date: 2018-01-29 07:45:15
Message-ID: CAHDDfCk-=B28DHm+PXwVn_ZdZD_DunP-Yos5K9Pq_mK_mzXGuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-01-29 08:04:40 Re: pgsql: Local partitioned indexes
Previous Message Amit Langote 2018-01-29 07:28:54 Re: unique indexes on partitioned tables