Horton

Re: [HACKERS] [PATCH] Generic type subscripting

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Andres Freund <andres@anarazel.de>, Alexander Korotkov <aekorotkov@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, David Steele <david@pgmasters.net>, Nikita Glukhov <n.gluhov@postgrespro.ru>, Alvaro Herrera <alvherre@2ndquadrant.com>, David Fetter <david@fetter.org>, Thomas Munro <thomas.munro@gmail.com>, Oleksandr Shulgin <oleksandr.shulgin@zalando.de>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, Oleg Bartunov <obartunov@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-17T20:29:35Z
Lists: pgsql-hackers 
Dmitry Dolgov <9erthalion6@gmail.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

Commits

  1. Throw error when assigning jsonb scalar instead of a composite object

  2. Filling array gaps during jsonb subscripting

  3. Implementation of subscripting for jsonb

  4. Allow ALTER TYPE to update an existing type's typsubscript value.

  5. Allow subscripting of hstore values.

  6. Support subscripting of arbitrary types, not only arrays.

  7. jit: Reference function pointer types via llvmjit_types.c.

  8. Teach contain_leaked_vars that assignment SubscriptingRefs are leaky.

  9. jit: Correct parameter type for generated expression evaluation functions.

  10. Renaming for new subscripting mechanism

  11. Fix assertion failure for SSL connections.

  12. Teach eval_const_expressions() to handle some more cases.