> On 19 September 2017 at 10:21, Arthur Zakirov <a.zaki...@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 <9erthali...@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.
