Re: [HACKERS] proposal: schema variables
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] proposal: schema variables |
Дата | |
Msg-id | 1f204fb8-afe6-006d-853b-4da05b416840@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: schema variables (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] proposal: schema variables
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: