Hi 2018-05-01 3:56 GMT+02:00 Peter Eisentraut <peter.eisentr...@2ndquadrant.com >:
> 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 >
