Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
> On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote:
>> We can certainly reconsider the API for the parsing hook if there's
>> really a good reason for these to be different types, but it seems
>> like that would just be encouraging poor design.

> To be more specific, this is the current behaviour (an example from the
> tests) and it doesn't seem right:

> =# update test_jsonb_subscript
> set test_json['a'] = 3 where id = 1;
> UPDATE 1
> =# select jsonb_typeof(test_json->'a')
> from test_jsonb_subscript where id = 1;
> jsonb_typeof
> --------------
> string

I'm kind of unmoved by that example, because making it better would
require more guessing about what the user wanted than I care for.

You could imagine, perhaps, that the subscript parsing hook gives
back a list of potential assignment source types, or that we make
it responsible for transforming the source expression as well as
the subscripts and then let it do something like that internally.
But that just opens the door to confusion and ambiguity. We already
had this discussion a few months ago, as I recall, when you wanted
to try assignment transforms to both text and integer but I pointed
out that both ways would succeed in some cases. The assignment
coercion rules are only intended to be used when there is *exactly
one* possible result type. I'd only be willing to accept multiple
possible coercion target types if we backed off the coercion level
to "implicit" to make multiple matches less likely (which is exactly
what we do when resolving input types for functions). But I'm
afraid that doing so would break more cases than it improves.
It would certainly break existing queries for array assignment.

I'm rather inclined to think that the result of subscripting a
jsonb (and therefore also the required source type for assignment)
should be jsonb, not just text. In that case, something like
update ... set jsoncol['a'] = 3
would fail, because there's no cast from integer to jsonb. You'd
have to write one of
update ... set jsoncol['a'] = '3'
update ... set jsoncol['a'] = '"3"'
to clarify how you wanted the input to be interpreted.
But that seems like a good thing, just as it is for jsonb_in.

The background for my being so down on this is that it reminds me
way too much of the implicit-casts-to-text mess that we cleaned up
(with great pain and squawking) back around 8.3. It looks to me
like you're basically trying to introduce multiple implicit casts
to jsonb, and I'm afraid that's just as bad an idea. At the very
least, if we do do it I don't see why it should only happen in the
context of subscripted assignment.

regards, tom lane