Re: [HACKERS] [PATCH] Generic type subscripting

Thank you for fixing. On Tue, Nov 07, 2017 at 09:00:43PM +0100, Dmitry Dolgov wrote: > > > +Datum > > > +custom_subscripting_parse(PG_FUNCTION_ARGS) > > > +{ > > > + boolisAssignment = PG_GETARG_BOOL(0); > > > > Here isAssignment is unused variable, so it could be

Re: [HACKERS] [PATCH] Generic type subscripting

On Sun, Oct 29, 2017 at 10:56:19PM +0100, Dmitry Dolgov wrote: > > So, here is the new version of patch that contains modifications we've > discussed, namely: > > * store oids of `parse`, `fetch` and `assign` functions > > * introduce dependencies from a data type > > * as a side effect of

Re: [HACKERS] [PATCH] Generic type subscripting

> On Fri, Sep 22, 2017 at 3:51 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 9/21/17 11:24, Dmitry Dolgov wrote: >> One last thing that I need to clarify. Initially there was an idea to >> minimize changes in `pg_type` > > I see, but there is no value in that if it makes

Re: [HACKERS] [PATCH] Generic type subscripting

On Fri, Sep 22, 2017 at 3:51 PM, Peter Eisentraut wrote: > On 9/21/17 11:24, Dmitry Dolgov wrote: >> One last thing that I need to clarify. Initially there was an idea to >> minimize changes in `pg_type` > > I see, but there is no value in that if it makes

Re: [HACKERS] [PATCH] Generic type subscripting

On 9/21/17 11:24, Dmitry Dolgov wrote: > One last thing that I need to clarify. Initially there was an idea to > minimize changes in `pg_type` I see, but there is no value in that if it makes everything else more complicated. -- Peter Eisentraut http://www.2ndQuadrant.com/

Re: [HACKERS] [PATCH] Generic type subscripting

> On 20 September 2017 at 17:19, Arthur Zakirov wrote: > As a conclusion: > * additional field are needed to pg_type for *_fetch and *_assign functions to solve dependency problem One last thing that I need to clarify. Initially there was an idea to minimize changes in

Re: [HACKERS] [PATCH] Generic type subscripting

On Wed, Sep 20, 2017 at 09:35:06AM -0400, Peter Eisentraut wrote: > > The difference is that those create associations between two separate > objects (cast: type1 <-> type2, transform: type <-> language). A > subscripting is just a property of a type. > > -- > Peter Eisentraut

Re: [HACKERS] [PATCH] Generic type subscripting

On 9/20/17 04:12, Arthur Zakirov wrote: > On Tue, Sep 19, 2017 at 09:01:57PM -0400, Peter Eisentraut wrote: >> Would you mind posting a summary of how you go here? > > There were several points here to me: > - it is necessary to solve the dependency problem (it can be solved also by > adding

Re: [HACKERS] [PATCH] Generic type subscripting

On Tue, Sep 19, 2017 at 09:01:57PM -0400, Peter Eisentraut wrote: > Would you mind posting a summary of how you go here? There were several points here to me: - it is necessary to solve the dependency problem (it can be solved also by adding several oid fields to the pg_type) - users may want to

Re: [HACKERS] [PATCH] Generic type subscripting

On 9/18/17 05:39, Arthur Zakirov wrote: > On Mon, Sep 18, 2017 at 10:31:54AM +0200, Dmitry Dolgov wrote: >> Just to clarify, do you mean that `CREATE SUBSCRIPTING FOR` would only make >> a >> dependency record? In this case `DROP SUBSCRIPTING FOR` actually means just >> drop an init function. > I

Re: [HACKERS] [PATCH] Generic type subscripting

> On 19 September 2017 at 10:21, Arthur Zakirov 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

Re: [HACKERS] [PATCH] Generic type subscripting

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 > > -

Re: [HACKERS] [PATCH] Generic type subscripting

> On 18 September 2017 at 11:39, Arthur Zakirov 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 > -

Re: [HACKERS] [PATCH] Generic type subscripting

On Mon, Sep 18, 2017 at 10:31:54AM +0200, Dmitry Dolgov wrote: > Just to clarify, do you mean that `CREATE SUBSCRIPTING FOR` would only make > a > dependency record? In this case `DROP SUBSCRIPTING FOR` actually means just > drop an init function. I think it would be good to add new catalog

Re: [HACKERS] [PATCH] Generic type subscripting

> On 17 September 2017 at 23:34, Arthur Zakirov wrote: > > I have put some thought into it. What about the following syntax? > > CREATE SUBSCRIPTING FOR type_name > INITFUNC = subscripting_init_func > FETCHFUNC = subscripting_fetch_func > ASSIGNFUNC =

Re: [HACKERS] [PATCH] Generic type subscripting

Arthur Zakirov writes: > CREATE SUBSCRIPTING FOR type_name > INITFUNC = subscripting_init_func > FETCHFUNC = subscripting_fetch_func > ASSIGNFUNC = subscripting_assign_func > DROP SUBSCRIPTING FOR type_name Reasonable, but let's make the syntax more like other

Re: [HACKERS] [PATCH] Generic type subscripting

On Sun, Sep 17, 2017 at 12:27:58AM +0200, Dmitry Dolgov wrote: > spite of what form this step will be. Maybe it's possible to make something > like `CREATE FUNCTION ... FOR SUBSCRIPTING`, then verify that assign/extract > functions are presented and notify user if he missed them (but I would >

Re: [HACKERS] [PATCH] Generic type subscripting

> On 17 September 2017 at 00:04, Arthur Zakirov wrote: > > In my opinion, 'DEPENDS ON' syntax is not actually appropriate here. It > also looks like a not very good hack to me. Hm...why do you think about it as a hack? > Moreover user can implement subscripting to its

Re: [HACKERS] [PATCH] Generic type subscripting

On Fri, Sep 15, 2017 at 10:02:00PM +0200, Dmitry Dolgov wrote: > > So, I've implemented a patch for that in form of a `DEPENDS ON` syntax for > creating a function. In my opinion, 'DEPENDS ON' syntax is not actually appropriate here. It also looks like a not very good hack to me. Moreover user

Re: [HACKERS] [PATCH] Generic type subscripting

> On 11 September 2017 at 23:45, Tom Lane wrote: > > Dmitry Dolgov <9erthali...@gmail.com> writes: > >> On 11 September 2017 at 23:19, Tom Lane wrote: > >> Uh, what? Sure you can. Just because the existing code never has a > >> reason to create such a

Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthali...@gmail.com> writes: >> On 11 September 2017 at 23:19, Tom Lane wrote: >> Uh, what? Sure you can. Just because the existing code never has a >> reason to create such a dependency doesn't mean it wouldn't work. > Well, I thought that `pg_depend` was

Re: [HACKERS] [PATCH] Generic type subscripting

> On 11 September 2017 at 23:19, Tom Lane wrote: > > Uh, what? Sure you can. Just because the existing code never has a > reason to create such a dependency doesn't mean it wouldn't work. Well, I thought that `pg_depend` was not intended to be used from user-defined code

Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthali...@gmail.com> writes: > About dependencies between functions - as far as I understand one cannot > create a `pg_depend` entry or any other kind of dependencies between > custom user-defined functions. Uh, what? Sure you can. Just because the existing code never has a

Re: [HACKERS] [PATCH] Generic type subscripting

> On 9 September 2017 at 23:33, Arthur Zakirov wrote: > PostgreSQL and documentation with the patch compiles without any errors. All > regression tests passed. Thank you! > But honestly I still cannot say that I agree with *_extract() and *_assign() > functions

Re: [HACKERS] [PATCH] Generic type subscripting

On Thu, Sep 07, 2017 at 10:49:54PM +0200, Dmitry Dolgov wrote: > On 29 August 2017 at 22:42, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > > To make a review little bit easier I've divided the patch into a few > smaller parts. > > Apparently I forgot about subscripting for the name data

Re: [HACKERS] [PATCH] Generic type subscripting

On Wednesday, 10 May 2017 23:43:10 MSK, Dmitry Dolgov wrote: > So, a few words about current state of the patch: > > * after a lot of serious improvements general design of this feature is > agreeable > > * we introduced a lot of small changes to polish it > > * I rebased the patch on the

Re: [HACKERS] [PATCH] Generic type subscripting

On 05.04.2017 16:06, Arthur Zakirov wrote: I'd like to focus on "refevalfunc" and "refnestedfunc" fields as I did earlier. I think using Oid type for them is a bad approach. "..._fetch" and "..._assign" functions in catalog is unnecessary movement to me. User of subscript of his type may think

Re: [HACKERS] [PATCH] Generic type subscripting

On 05.04.2017 16:06, Arthur Zakirov wrote: On 04.04.2017 15:41, Dmitry Dolgov wrote: Sorry for late reply. Here is a new version of the patch, I rebased it and fixed those issues you've mentioned (pretty nasty problems, thank you for noticing). Thank you! I've looked at the patch again.

Re: [HACKERS] [PATCH] Generic type subscripting

On 04.04.2017 15:41, Dmitry Dolgov wrote: Sorry for late reply. Here is a new version of the patch, I rebased it and fixed those issues you've mentioned (pretty nasty problems, thank you for noticing). Thank you! I've looked at the patch again. I'd like to focus on "refevalfunc" and

Re: [HACKERS] [PATCH] Generic type subscripting

2017-03-28 19:31 GMT+03:00 Dmitry Dolgov <9erthali...@gmail.com>: > On 28 March 2017 at 12:08, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> >> Wow, I didn't notice that, sorry - will fix it shortly. > > So, here is the corrected version of the patch. Thank you! The patch looks good to me. But

Re: [HACKERS] [PATCH] Generic type subscripting

2017-03-31 5:32 GMT+03:00 Dmitry Dolgov <9erthali...@gmail.com>: > On 30 March 2017 at 19:36, Arthur Zakirov wrote: >> >> The last point is about the tutorial. As Tom pointed it is not useful when >> the tutorial doesn't execute. It happens because there is not "custom"

Re: [HACKERS] [PATCH] Generic type subscripting

On 30 March 2017 at 19:36, Arthur Zakirov wrote: > > The last point is about the tutorial. As Tom pointed it is not useful when the tutorial doesn't execute. It happens because there is not "custom" type in subscripting.sql. I'm confused. Maybe I'm missing something,

Re: [HACKERS] [PATCH] Generic type subscripting

On 29.03.2017 20:14, Arthur Zakirov wrote: I wanted to implement subscripting for ltree or hstore extensions. Subscripting for ltree looks more interesting. Especially with slicing. But I haven't done it yet. I hope that I will implement it tomorrow. ltree - I've implemented fetching

Re: [HACKERS] [PATCH] Generic type subscripting

On 28.03.2017 19:31, Dmitry Dolgov wrote: On 28 March 2017 at 12:08, Dmitry Dolgov <9erthali...@gmail.com > wrote: Wow, I didn't notice that, sorry - will fix it shortly. So, here is the corrected version of the patch. I have some picky comments. I'm not sure

Re: [HACKERS] [PATCH] Generic type subscripting

On 28 March 2017 at 11:58, Arthur Zakirov wrote: > > Your patch reverts commits from 25-26 march. And therefore contains 15000 lines. Wow, I didn't notice that, sorry - will fix it shortly.

Re: [HACKERS] [PATCH] Generic type subscripting

Hello, On 27.03.2017 23:28, Dmitry Dolgov wrote: Here is a new version of this patch. What was changed: * I rebased code against the latest version of master and adapted recent changes about the expression execution * Several names (functions and related pg_type column) were changed * A

Re: [HACKERS] [PATCH] Generic type subscripting

On 24.03.2017 18:29, Tom Lane wrote: David Steele writes: Do you have an idea when you will have a patch ready? We are now into the last week of the commitfest. I see one question for Tom, but it's not clear that this would prevent you from producing a new patch. FWIW,

Re: [HACKERS] [PATCH] Generic type subscripting

David Steele writes: > Do you have an idea when you will have a patch ready? We are now into > the last week of the commitfest. I see one question for Tom, but it's > not clear that this would prevent you from producing a new patch. FWIW, I'm up to my eyeballs in Andres'

Re: [HACKERS] [PATCH] Generic type subscripting

On 24 March 2017 at 15:39, David Steele wrote: > > Do you have an idea when you will have a patch ready? Yes, I'll prepare a new version with most important changes in two days.

Re: [HACKERS] [PATCH] Generic type subscripting

Hi Dmitry, On 3/21/17 4:42 PM, Dmitry Dolgov wrote: On 21 March 2017 at 18:16, David Steele > wrote: This thread has been idle for over a week. Yes, sorry for the late reply. I'm still trying to find a better solution for some of the

Re: [HACKERS] [PATCH] Generic type subscripting

> On 21 March 2017 at 18:16, David Steele wrote: > > This thread has been idle for over a week. Yes, sorry for the late reply. I'm still trying to find a better solution for some of the problems, that arose in this patch. > On 15 March 2017 at 00:10, Tom Lane

Re: [HACKERS] [PATCH] Generic type subscripting

Hi Dmitry, On 3/14/17 7:10 PM, Tom Lane wrote: Dmitry Dolgov <9erthali...@gmail.com> writes: [ generic_type_subscription_v7.patch ] I looked through this a bit. This thread has been idle for over a week. Please respond and/or post a new patch by 2017-03-24 00:00 AoE (UTC-12) or this

Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthali...@gmail.com> writes: > [ generic_type_subscription_v7.patch ] I looked through this a bit. I think that the basic design of having a type-specific parse analysis function that returns a constructed SubscriptingRef node is fine. I'm not totally excited about the naming

Re: [HACKERS] [PATCH] Generic type subscripting

Peter Eisentraut writes: > I see a possible problem here: This design only allows one subscripting > function. But what you'd really want in this case is at least two: one > taking an integer type for selecting by array index, and one taking text > for

Re: [HACKERS] [PATCH] Generic type subscripting

On 2/28/17 13:02, Dmitry Dolgov wrote: > + > +-- Extract value by key > +SELECT ('{"a": 1}'::jsonb)['a']; > + > +-- Extract nested value by key path > +SELECT ('{"a": {"b": {"c": 1}}}'::jsonb)['a']['b']['c']; > + > +-- Extract element by index > +SELECT ('[1, "2", null]'::jsonb)['1']; > + > +--