Re: [HACKERS] [PATCH] Generic type subscripting - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [HACKERS] [PATCH] Generic type subscripting
Date
Msg-id CA+q6zcVOCOCtNm7OxDkc0vanOG+6o-58OjotRF16eaKP47dZaQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Generic type subscripting  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
Responses Re: [HACKERS] [PATCH] Generic type subscripting
List pgsql-hackers
> On 18 September 2017 at 11:39, Arthur Zakirov <a.zakirov@postgrespro.ru> 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`?

> And command 'CREATE SUBSCRIPTING' should add an entry to the pg_subscripting table. It also adds entries to the pg_depend table: dependency between pg_type and pg_subscripting, dependency between pg_type and pg_proc.
> 'DROP SUBSCRIPTING' should drop this entries, it should not drop init function.

Why we should keep those subscripting functions? From my understanding they're
totally internal and useless without subscripting context.

Overall I have only one concern about this suggestion - basically it changes
nothing from the perspective of functionality or implementation quality. The
only purpose of it is to make a `subscripting` entity more explicit at the
expense of overhead of having one more catalog table and little bit more
complexity. I'm not really sure if it's necessary or not, and I would
appreciate any commentaries about that topic from the community (to make me
more convinced that this is a good decision or not).

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Perform only oneReadControlFile() during startup.