On 4/20/18 13:45, Pavel Stehule wrote: > I dunno, it seems awfully different to me. There's only one "column", > right? What code is really shared here? Are constraints and triggers > even desirable feature for variables? What would be the use case? > > > The schema variable can hold composite value. The patch allows to use > any composite type or adhoc composite values > > DECLARE x AS compositetype; > DECLARE x AS (a int, b int, c int);
I'm not sure that this anonymous composite type thing is such a good idea. Such a variable will then be incompatible with anything else, because it's of a different type. In any case, I find that a weak argument for storing this in pg_class. You could just as well create these pg_class entries implicitly and link them from "pg_variable", same as composite types have a main entry in pg_type and additional stuff in pg_class. > I think stuffing this into pg_class is pretty strange. > > It will be if variable is just scalar value without any possibilities. > But then there is only low benefit > > The access rights implementation is shared with other from pg_class too. In DB2, the privileges for variables are named READ and WRITE. That would make more sense to me than reusing the privilege names for tables. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
