Re: [HACKERS] proposal: schema variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: schema variables
Дата
Msg-id CAFj8pRCptLktoDiCYK_rL2OgOGR-+B1QrNUGcK+Mkqi+KhWj+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: schema variables  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] proposal: schema variables  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Дерево обсуждения


2018-04-20 17:32 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
On Tue, Apr 17, 2018 at 12:28 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> It true, so there are lot of "unused" attributes for this purpose, but there
> is lot of shared attributes, and lot of shared code. Semantically, I see
> variables in family of sequences, tables, indexes, views. Now, it shares
> code, and I hope in next steps more code can be shared - constraints,
> triggers.

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);

Constraints are clear, no. 

Triggers are strange maybe, but why not - it can be used like enhanced constraints, can be used for some value calculations, ..


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.

Regards

Pavel
 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Foreign keys and partitioned tables
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Postgresql9.6 type cache invalidation issue - different behave ofpsql and pg regress