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)
