Re: [HACKERS] [PATCH] Generic type subscripting
Tom Lane <tgl@sss.pgh.pa.us>
Dmitry Dolgov <9erthalion6@gmail.com> writes: >> On Wed, Dec 09, 2020 at 04:59:34PM -0500, Tom Lane wrote: >> 0001 adds the ability to attach a subscript handler to an existing >> data type with ALTER TYPE. This is clearly going to be necessary >> if we want extension types to be able to use this facility. The >> only thing that I think might be controversial here is that I did >> not add the ability to set pg_type.typelem. > I'm curious what could be the use case for setting pg_type.typelem for > subscripting? I don't see this that much controversial, but maybe I'm > missing something. If you want the result of subscripting to be "text" or some other built-in type, then clearly there's no need to use typelem for that, you can just refer to the standard OID macros. The potential use-case that I thought of for setting typelem is where an extension defines types A and B and would like subscripting of B to yield A. Installing A's OID as B.typelem would save a catalog lookup during subscript parsing, and remove a bunch of edge failure cases such as what happens if A gets renamed. However, given the dependency behavior, this would also have the effect of "you can't drop A without dropping B, and you can't modify A in any interesting way either". That would be annoyingly restrictive if there weren't any actual physical containment relationship. But on the other hand, maybe it's acceptable and we just need to document it. The other issue is what about existing stored SubscriptingRef structs. If our backs were to the wall I'd think about removing the refelemtype field so there's no stored image of typelem that needs to be updated. But that would incur an extra catalog lookup in array_exec_setup, so I don't much like it. If we do add the ability to set typelem, I'd prefer to just warn people to not change it once they've installed a subscript handler. Anyway, between those two issues I'm about -0.1 on adding a way to alter typelem. I won't fight hard if somebody wants it, but I'm inclined to leave it out. >> +1 using subscripts for hstore is nice idea > Yeah, I also find it's a good suggestion, the implementation seems fine > as well. As a side note, I'm surprised hstore doesn't have any > functionality to update values, except hstore_concat. Yeah. I cribbed the subscript-fetch implementation from hstore_fetchval, but was surprised to find that there wasn't any direct equivalent function for subscript-store. I guess people have gotten by with concat, but it's not exactly an obvious way to do things. regards, tom lane
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