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
|
| Список | 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
В списке pgsql-hackers по дате отправления: