Re: [HACKERS] [PATCH] Generic type subscripting

> On 19 September 2017 at 10:21, Arthur Zakirov <a.zakirov@postgrespro.ru> wrote:

> On Mon, Sep 18, 2017 at 12:25:04PM +0200, Dmitry Dolgov wrote:

>> > I think it would be good to add new catalog table. It may be named as

>> pg_type_sbs or pg_subscripting (second is better I think).

>> > This table may have the fields:

>> > - oid

>> > - sbstype

>> > - sbsinit

>> > - sbsfetch

>> > - sbsassign

>>

>> What is `sbstype`?

>

>'sbstype' is oid of type from pg_type for which subscripting is created. I.e. pg_type may not have the 'typsubsparse' field.

I'm confused, why do we need it? I mean, isn't it enough to have a subscripting

oid in a pg_type record?

> On 18 September 2017 at 12:25, Dmitry Dolgov <9erthalion6@gmail.com> wrote:

>

> Overall I have only one concern about this suggestion - basically it changes

> nothing from the perspective of functionality or implementation quality.

Few more thoughts about this point. Basically if we're going this way (i.e.

having `pg_subscripting`) there will be one possible change of functionality -

in this case since we store oids of all the required functions, we can pass

them to a `parse` function (so that a custom extension does not need to resolve

them every time).

At the same time there are consequences of storing `pg_subscripting`, e.g.:

* I assume the performance would be worse because we have to do more actions to

  actually call a proper function.

* The implementation itself will be little bit more complex I think.

* Should we think about other functionality besides `CREATE` and `DROP`, for

  example `ALTER` (as far as I see aggregations support that).

and maybe something else that I don't see now.