Re: [HACKERS] [PATCH] Generic type subscripting

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <chap@anastigmatix.net>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Dmitry Dolgov <9erthalion6@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:50:37Z
Lists: pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> On 12/17/20 14:28, Tom Lane wrote:
>> 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.

> Would it be feasible to analyze that as something like an implicit
> 'treat as' with the type of the assignment target?

TBH, I think that expending any great amount of effort in that direction
would be a big waste of effort.  We already have strongly-typed
composite types.  The use-case for json is where you *don't* have
ironclad guarantees about what the structure of the data is.

As for doing it implicitly, that is still going to fall foul of the
fundamental problem, which is that we don't have the info at parse
time.  Examples with constant values for the json input are not what
to look at, because they'll just mislead you as to what's possible.

			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.