Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fDLiA-0003xn-Rs for pgsql-hackers@arkaria.postgresql.org; Tue, 01 May 2018 03:12:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fDLi9-00034q-5N for pgsql-hackers@arkaria.postgresql.org; Tue, 01 May 2018 03:12:13 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fDLi8-00034O-O0 for pgsql-hackers@lists.postgresql.org; Tue, 01 May 2018 03:12:12 +0000 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fDLi5-0000BH-Oe for pgsql-hackers@postgresql.org; Tue, 01 May 2018 03:12:11 +0000 Received: by mail-wm0-x241.google.com with SMTP id n10so17189836wmc.1 for ; Mon, 30 Apr 2018 20:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F0cIPtLcOja79+TyUp4kcXXa+d0LSG+aw4/jhFPHf3Y=; b=PaEvECCM7JEiCvZQoYo2a9Np6SIDkDOPrYn2icnUIpRho2SxJKB6JtVXtAR6D6jkYi HfOXemlqsq5r0+MItWXNgttEwXuZ7Ikme8ADaslAsvl6gGJcKsxcweHXS5bP4HL3vyrb cg7IxGdvLGr2BCc60q9q6kpXB96rE98qWMcmjK1YTgwN+hYMJdTcrzfyu49ENPhVyEte t7mKnyzQDkui6FMNC4z/DdtW0VFvp2fXlNjdD9XEg2G4Wi5D4BAVy5IjFhtJ97xaJsi0 AeXI6ct2cUymkIsOU7QWzLZUDAopvuAA7hkEAUX66RVaNvtMQKK+NBbLUnXWQtKYh7E0 B05w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F0cIPtLcOja79+TyUp4kcXXa+d0LSG+aw4/jhFPHf3Y=; b=WQUKlpk5z58umhRltJ/v3R1kQdUgNJttcxF2O3MU7KNgk76jP1J9kYvfKQkw5oIbgX UD4t+4mZAi4PXeH+5tEKu7zvhUUrRao8OgYA+hsApszcsWQnD1IkxtDAMP6zBHoCerg+ gbWS+H08N5+/Lhi3MCEfUvEzgl3M6T9H3qeCIV33bInNkHY7cy2ogfqFCQe3VBUvCNNT 1L93/N1xrqo5fkxLMb/RBTvOeJl7WGPP2OpCtKmAocdvKg9ZotXqvxMZrlhulH2JYgFB DU5liaXUSXUPnRgoCiB0/nHObI1IK0jhW+QOSD7sJdKB/fCP97RpoXAOjEXhGWSO5xZa 433g== X-Gm-Message-State: ALQs6tAX8hmuSflXxHbyhlbzSu1Ws1Yn8XdlBS1UemAEHxkoMmEylPib B0NFWMq9PJYMghNxaY62pK4bhkMl1r01rj6uTe4= X-Google-Smtp-Source: AB8JxZopx9XMWXw39xgK01621tnl3SHOVSpy+qckdFGIVLR0btJA9w59OIJAGhG/CJgE9qjl8AX3Bi0w6W34nSl4n70= X-Received: by 10.28.141.144 with SMTP id p138mr9180126wmd.153.1525144327894; Mon, 30 Apr 2018 20:12:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.155.26 with HTTP; Mon, 30 Apr 2018 20:11:27 -0700 (PDT) In-Reply-To: <1f204fb8-afe6-006d-853b-4da05b416840@2ndquadrant.com> References: <20180417141410.GA7917@zakirov.localdomain> <1f204fb8-afe6-006d-853b-4da05b416840@2ndquadrant.com> From: Pavel Stehule Date: Tue, 1 May 2018 05:11:27 +0200 Message-ID: Subject: Re: [HACKERS] proposal: schema variables To: Peter Eisentraut Cc: Robert Haas , Arthur Zakirov , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="001a11474858e53cf6056b1c5507" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a11474858e53cf6056b1c5507 Content-Type: text/plain; charset="UTF-8" Hi 2018-05-01 3:56 GMT+02:00 Peter Eisentraut : > 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 > --001a11474858e53cf6056b1c5507 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

2018-05-01 3:56 GMT+02:00 Peter Eisentraut <= ;pete= r.eisentraut@2ndquadrant.com>:
On 4/20/18 13:45, Pavel Stehule wrote:
>=C2=A0 =C2=A0 =C2=A0I dunno, it seems awfully different to me.=C2=A0 Th= ere's only one "column",
>=C2=A0 =C2=A0 =C2=A0right?=C2=A0 What code is really shared here?=C2=A0= Are constraints and triggers
>=C2=A0 =C2=A0 =C2=A0even desirable feature for variables?=C2=A0 What wo= uld be the use case?
>
>
> The schema variable can hold composite value. The patch allows to use<= br> > 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.=C2=A0 Such a variable will then be incompatible with anything else, because it's of a different type.

U= sing anonymous composite type variable is just shortcut for situations when= mentioned feature is not a problem. These variables are global, so there c= an be only one variable of some specific composite type, and incompatibilit= y with others is not a issue.

This feature can be interes= ting for short live temp variables - these variables can be used for parame= trization of anonymous block.

But this feature is not si= gnificant, 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 entr= y in
pg_type and additional stuff in pg_class.

>=C2=A0 =C2=A0 =C2=A0I think stuffing this into pg_class is pretty stran= ge.
>
> 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 to= o.

In DB2, the privileges for variables are named READ and WRITE.=C2=A0= That
would make more sense to me than reusing the privilege names for tables.

good idea

Regards

Pavel
--
Peter Eisentraut=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://w= ww.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--001a11474858e53cf6056b1c5507--