public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Pavel Stehule <pavel.stehule@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Arthur Zakirov <a.zakirov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] proposal: schema variables
Date: Tue, 1 May 2018 05:11:27 +0200
Message-ID: <CAFj8pRB+ER3huHOZK_fMAdG=oSTx2U1Kq+MqUX4Y+jw2ZbaRFw@mail.gmail.com> (raw)
In-Reply-To: <1f204fb8-afe6-006d-853b-4da05b416840@2ndquadrant.com>
References: <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
<20180417141410.GA7917@zakirov.localdomain>
<CAFj8pRD3RGW7zoHs2-4FgUKnV7TmHYbZiQYq1KS+KgwS3W30bQ@mail.gmail.com>
<CA+Tgmoaf44_UONp7zHgmkRwFNPbr7-7XnuZYu_JqSdZMrLi3cA@mail.gmail.com>
<CAFj8pRCptLktoDiCYK_rL2OgOGR-+B1QrNUGcK+Mkqi+KhWj+g@mail.gmail.com>
<1f204fb8-afe6-006d-853b-4da05b416840@2ndquadrant.com>
Hi
2018-05-01 3:56 GMT+02:00 Peter Eisentraut <peter.eisentraut@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
>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pavel.stehule@gmail.com, peter.eisentraut@2ndquadrant.com, robertmhaas@gmail.com, a.zakirov@postgrespro.ru, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal: schema variables
In-Reply-To: <CAFj8pRB+ER3huHOZK_fMAdG=oSTx2U1Kq+MqUX4Y+jw2ZbaRFw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox