Re: [HACKERS] [PATCH] Generic type subscripting
Pavel Stehule <pavel.stehule@gmail.com>
so 1. 8. 2020 v 16:30 odesílatel Dmitry Dolgov <9erthalion6@gmail.com> napsal: > > On Fri, Jul 31, 2020 at 03:35:22PM -0400, Tom Lane wrote: > > > > I started to look through this again, and really found myself wondering > > why we're going to all this work to invent what are fundamentally pretty > > bogus "features". The thing that particularly sticks in my craw is the > > 0005 patch, which tries to interpret a subscript of a JSON value as > either > > integer or text depending on, seemingly, the phase of the moon. I don't > > think that will work. For example, with existing arrays you can do > > something like arraycol['42'] and the unknown-type literal is properly > > cast to an integer. The corresponding situation with a JSON subscript > > would have no principled resolution. > > > > It doesn't help any that both coercion alternatives are attempted at > > COERCION_ASSIGNMENT level, which makes it noticeably more likely that > > they'll both succeed. But using ASSIGNMENT level is quite inappropriate > > in any context where it's not 100% certain what the intended type is. > > > > The proposed commit message for 0005 claims that this is somehow > improving > > our standards compliance, but I see nothing in the SQL spec suggesting > > that you can subscript a JSON value at all within the SQL language, so > > I think that claim is just false. > > It's due to my lack of writing skills. As far as I can remember the > discussion was about JSON path part of the standard, where one allowed > to use float indexes with implementation-defined rounding or truncation. > In this patch series I'm trying to think of JSON subscript as an > equivalent for JSON path, hence this misleading description. Having said > that, I guess the main motivation behind 0005 is performance > improvements. Hopefully Nikita can provide more insights. Overall back > when 0005 patch was suggested its implementation looked reasonable for > me, but I'll review it again. > > > Maybe this could be salvaged by flushing 0005 in its current form and > > having the jsonb subscript executor do something like "if the current > > value-to-be-subscripted is a JSON array, then try to convert the textual > > subscript value to an integer". Not sure about what the error handling > > rules ought to be like, though. > > I'm fine with the idea of separating 0005 patch and potentially prusuing > it as an independent item. Just need to rebase 0006, since Pavel > mentioned that it's a reasonable change he would like to see in the > final result. > +1 Pavel
Commits
-
Throw error when assigning jsonb scalar instead of a composite object
- aa6e46daf530 14.0 landed
-
Filling array gaps during jsonb subscripting
- 81fcc72e6622 14.0 landed
-
Implementation of subscripting for jsonb
- 676887a3b0b8 14.0 landed
-
Allow ALTER TYPE to update an existing type's typsubscript value.
- 8c15a297452e 14.0 landed
-
Allow subscripting of hstore values.
- 0ec5f7e78231 14.0 landed
-
Support subscripting of arbitrary types, not only arrays.
- c7aba7c14efd 14.0 landed
-
jit: Reference function pointer types via llvmjit_types.c.
- df99ddc70b97 14.0 landed
-
Teach contain_leaked_vars that assignment SubscriptingRefs are leaky.
- c0549cee07ea 13.2 landed
- 62ee70331336 14.0 landed
- 3470caa21bf8 10.16 landed
- 2f1997b1551a 12.6 landed
- 1f229f4fdcf8 11.11 landed
- 17c77c8c90f7 9.6.21 landed
-
jit: Correct parameter type for generated expression evaluation functions.
- 5da871bfa1ba 14.0 landed
- 1e16ad101459 11.11 landed
- 27b57f806dc2 12.6 landed
- 01c6370a32e5 13.2 landed
-
Renaming for new subscripting mechanism
- 558d77f20e4e 12.0 landed
-
Fix assertion failure for SSL connections.
- ab69ea9feeb9 12.0 cited
-
Teach eval_const_expressions() to handle some more cases.
- 3decd150a2d5 11.0 cited