Re: [HACKERS] [PATCH] Generic type subscripting

čt 17. 12. 2020 v 20:28 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > čt 17. 12. 2020 v 19:49 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> >> So ... what's the problem with that? Seems like what you should put
> >> in and what you should get out should be the same type.
>
> > I don't think so. For XML or JSON the target can be different, and it
> can
> > safe one CAST
>
> > DECLARE
> > n int;
> > v varchar;
> > js jsonb default '{"n": 100, "v" : "Hello"};
> > BEGIN
> > n := js['n'];
> > v := js['v'];
>
> If you're imagining that js['n'] and js['v'] would emit different
> datatypes, forget it. That would require knowing at parse time
> what the structure of the json object will be at run time.
>

My idea was a little bit different. When we know the target type (in this
example int or varchar), then we can *theoretically* push this information
to the subscribing function. This optimization is used in the XMLTABLE
function. Now the subscribing function returns JSONB, although internally
inside the source value, there are stored integer and varchar values. So
the returned value should be converted to jsonb first. Immediately it is
casted to the target type outside. My idea was to join the subscription
function and outer cast to one functionality, that allows to skip casting
when it is not necessary. It will be known in run time. Sure. But because
the outer cast and subscription function are separate things, then it is
not possible to skip the outer cast.

Pavel

> But in any case, the discussion here is about the source datatype
> for an assignment, which this example doesn't even contain.
>
> regards, tom lane
>