Re: [HACKERS] proposal: schema variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: schema variables
Date
Msg-id CAFj8pRCptLktoDiCYK_rL2OgOGR-+B1QrNUGcK+Mkqi+KhWj+g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: schema variables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] proposal: schema variables
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Foreign keys and partitioned tables
Next
From: Pavel Stehule
Date:
Subject: Re: Postgresql9.6 type cache invalidation issue - different behave ofpsql and pg regress