From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Steele <david(at)pgmasters(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Generic type subscripting |
Date: | 2017-09-19 12:11:52 |
Message-ID: | CA+q6zcX1jmDwFmQh03-UjM9o3os8iL6b15EwU-LZHzTEq8VOsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 19 September 2017 at 10:21, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)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(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-09-19 12:19:10 | Re: postgres_fdw bug in 9.6 |
Previous Message | Michael Paquier | 2017-09-19 12:02:32 | Re: src/test/subscription/t/005_encoding.pl is broken |