Horton

Re: [HACKERS] [PATCH] Generic type subscripting

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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:25:55Z
Lists: pgsql-hackers 
č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.
>
>                         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.