On 2021-Oct-08, Matthias van de Meent wrote:
> That's a good point, but if we're extending this syntax to allow the
> ability of including other types, then I'd instead extend the syntax
> that of below, so that the type of the dictionary entries is required
> in the syntax:
>
> CREATE TYPE name AS DICTIONARY OF jsonb [ ( ...entries ) ] [ WITH (
> ...options ) ];
I don't think this gives you any guarantees of the sort you seem to
expect. See CREATE AGGREGATE as a precedent where there are some
options in the parenthesized options list you cannot omit.
> > The pg_type entry would have to provide some support procedure that
> > makes use of the dictionary in some way. This seems better than tying
> > the SQL object to a specific type.
>
> Agreed, but this might mean that much more effort would be required to
> get such a useful quality-of-life feature committed.
I don't understand what you mean by that. I'm not saying that the patch
has to provide support for any additional datatypes. Its only
obligation would be to provide a new column in pg_type which is zero for
all rows except jsonb, and in that row it is the OID of a
jsonb_dictionary() function that's called from all the right places and
receives all the right arguments.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"No tengo por qué estar de acuerdo con lo que pienso"
(Carlos Caszeli)
