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.
Using anonymous composite type variable is just shortcut for situations when mentioned feature is not a problem. These variables are global, so there can be only one variable of some specific composite type, and incompatibility with others is not a issue.
This feature can be interesting for short live temp variables - these variables can be used for parametrization of anonymous block.
But this feature is not significant, and can be removed from patch.
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.
good idea
Regards
Pavel
-- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
