Re: [HACKERS] [PATCH] Generic type subscripting

> On Thu, Feb 13, 2020 at 02:25:46PM +0100, Pavel Stehule wrote:
>
> > > I like patch 0006 - filling gaps by NULLs - it fixed my objections if I
> > > remember correctly. Patch 0005 - polymorphic subscribing - I had not a
> > > idea, what is a use case? Maybe can be good to postpone this patch. I
> > have
> > > not strong opinion about it, but generally is good to reduce size of
> > > initial patch. I have nothing against a compatibility with SQL, but this
> > > case doesn't looks too realistic for me, and can be postponed without
> > > future compatibility issues.
> >
> > The idea about 0005 is mostly performance related, since this change
> > (aside from being more pedantic with the standard) also allows to
> > squeeze out some visible processing time improvement. But I agree that
> > the patch series itself is too big to add something more, that's why I
> > concider 0005/0006 mosly as interesting ideas for the future.
> >
>
> patch 0006 is necessary from my perspective. Without it, behave of update
> is not practical. I didn't review of this patch mainly due issues that was
> fixed by 0006 patch

Oh, I see. The thing is that in how it is implemented right now 0006
depends on 0005. Originally I was against of doing anything different
than a regular jsonb functionality would do, but after the discussion
about jsonb_set and null arguments I figured that indeed it probably
makes sense to deviate in some certain cases. Eventually it depends on
the community feedback, so I can try to make 0006 an independent change
and we will see.

> > Yep, I wasn't paying much attention recently to this patch, will post
> > rebased and fixed version soon. At the same time I must admit, even if
> > at the moment I can pursue two goals - either to make this feature
> > accepted somehow, or make a longest living CF item ever - neither of
> > those goals seems reachable.
> >
>
> I think so this feature is not important for existing applications. But it
> allows to work with JSON data (or any other) more comfortable (creative) in
> plpgsql.

Yes, hopefully.