čt 17. 12. 2020 v 20:28 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes: > čt 17. 12. 2020 v 19:49 odesílatel Tom Lane <tgl@sss.pgh.pa.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.