Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8jMA-0002Ia-4e for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Oct 2017 08:54:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e8jM9-0007sX-2P for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Oct 2017 08:54:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e8jKZ-00059X-V8 for pgsql-hackers@postgresql.org; Sun, 29 Oct 2017 08:52:32 +0000 Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1e8jKV-0005qK-Ui for pgsql-hackers@postgresql.org; Sun, 29 Oct 2017 08:52:31 +0000 Received: by mail-qk0-x22b.google.com with SMTP id f199so12897071qke.2 for ; Sun, 29 Oct 2017 01:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adjust.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zkpT4CSOKltboICR9bwyJkaZxDTvnxABIrY8SRYiKUc=; b=HaLrLc4vCGDO3PGMGDGh3MUiF9yxCpEl/jzATjf0kmrJj88gh+YEL62UlpLw5VY08D sDbg20vp8loqFt/ZpayVp6m5lSXLk/mdnyi0NGvd10ML/KzgBQhTwhIWPRPph2unxlo0 ojyQFhCJNAxKCeozMoVOZNQ7g+8Zx5YtfXBoo7MSvA5cn7n7K/1j2lW7lkMeFikGoh4j EggBxeHVuYf1kDvKVpUggSumKwMmzuyp++PIV3gnV7kAnTwSp8s3edQAfGJe2nm6pgd4 VE4MdDJ/fwRV6raHRnlhUUWUQRIs+BPuKmqgUoft6p883VpnysVG1+/dYs5zpmKsuj8H pNCw== 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=zkpT4CSOKltboICR9bwyJkaZxDTvnxABIrY8SRYiKUc=; b=BgkbM1lbGwAaGhhxG2FwYEJsI6s96Ky0u7Hy+hgcSyb2gGDoei9qasgZn1HAUTtrW6 ChbZSju5+O82nwV91smNJ4nBnSXb+v0WjniTqJZ2XcQQUxxxI7bWNWkJtGOtrRwtKBnp 2PQQ4zFiHfpRVjHr8aeMTPoqUit5JZAMvYrBToG1xNgqvHQIT5voUOG21FvAVitIIyOu brIrTOouDAsi283onbiOqT1mkvhlXC7kg6x+wwVmFUjP3RW4+fLvgPC9Cr7+R69gyT7H CbYzCTf1ZF+fx6daaUATxJNrD8UeYycZ2UCpuTIzSSHVbE6L/oGVrN7ERZNRXQCf4FBE b24A== X-Gm-Message-State: AMCzsaVJk7IXRpBqCvqBwqfe/UyEE9lAXbuURacsiBmQ94QfdlpHSGZ8 umuO0zYXJWXSIjkfwMm1QPwN/BCEy39v6KqC71IbaA== X-Google-Smtp-Source: ABhQp+TSSsL0cd7LeS2aPEw8wFEovFHD9UrmMrEuUxC9f78053XwAEM5AIDRz4iMhDZcPv2NzHN9TenhMLD39Ni4Ldw= X-Received: by 10.55.142.4 with SMTP id q4mr8389460qkd.139.1509267146299; Sun, 29 Oct 2017 01:52:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.96.40 with HTTP; Sun, 29 Oct 2017 01:51:55 -0700 (PDT) In-Reply-To: References: From: Chris Travers Date: Sun, 29 Oct 2017 09:51:55 +0100 Message-ID: Subject: Re: proposal: schema variables To: Pavel Stehule Cc: PostgreSQL Hackers Content-Type: multipart/alternative; boundary="94eb2c083c6a2079f5055caba49a" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org --94eb2c083c6a2079f5055caba49a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 28, 2017 at 4:56 PM, Pavel Stehule wrote: > >> > The creating database objects and necessary infrastructure is the most > simple task of this project. I'll be more happy if there are zero > intersection because variables and GUC are designed for different purpose= s. > But due SET keyword the intersection there is. > > When I thinking about it, I have only one, but important reason, why I > prefer design new type of database object -the GUC are stack based with > different default granularity - global, database, user, session, function= . > This can be unwanted behave for variables - it can be source of hard to > detected bugs. I afraid so this behave can be too messy for usage as > variables. > > @1 I have not clean opinion about it - not sure if rights are good enough > - probably some user limits can be more practical - but can be hard to > choose result when some user limits and GUC will be against > I was mostly thinking that users can probably set things like work_mem and possibly this might be a problem. > @2 With variables typed custom GUC are not necessary > I don't know about that. For example with the geoip2lookup extension it is nice that you could set the preferred language for translation on a per user basis or the mmdb path on a per-db basis. > @3 Why you need it? It is possible with set_config function now. > Yeah you could do it safely with set_config and a CTE, but suppose I have: with a (Id, value) as (values (1::Int, 'foo'), (2, 'bar'), (3, 'baz')) SELECT set_config('custom_val', value) from a where id =3D 2; What is the result out of this? I would *expect* that this would probably run set_config 3 times and filter the output. > > Regards > > Pavel > > > > >> >> >>> regards >>> >>> Pavel >>> >>> >>> >> >> >> -- >> Best Regards, >> Chris Travers >> Database Administrator >> >> Tel: +49 162 9037 210 <+49%20162%209037210> | Skype: einhverfr | >> www.adjust.com >> Saarbr=C3=BCcker Stra=C3=9Fe 37a, 10405 Berlin >> >> >> > --=20 Best Regards, Chris Travers Database Administrator Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbr=C3=BCcker Stra=C3=9Fe 37a, 10405 Berlin --94eb2c083c6a2079f5055caba49a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 28, 2017 at 4:56 PM, Pavel Stehule <pavel.stehule@gm= ail.com> wrote:


The creating database objects an= d necessary infrastructure is the most simple task of this project. I'l= l be more happy if there are zero intersection because variables and GUC ar= e designed for different purposes. But due SET keyword the intersection the= re is.

When I thinking about it, I have only one, = but important reason, why I prefer design new type of database object -the = GUC are stack based with different default granularity - global, database, = user, session, function. This can be unwanted behave for variables - it can= be source of hard to detected bugs. I afraid so this behave can be too mes= sy for usage as variables.

@1 I have not clea= n opinion about it - not sure if rights are good enough - probably some use= r limits can be more practical - but can be hard to choose result when some= user limits and GUC will be against

I was mostly thinking that users can probably set t= hings like work_mem and possibly this might be a problem.
=C2=A0<= /div>
@2 With variables typed custom GU= C are not necessary

I don't know about that.=C2=A0 For example with the geoip2lookup= extension it is nice that you could set the preferred language for transla= tion on a per user basis or the mmdb path on a per-db basis.
=C2= =A0
@3 Why you need it? It is pos= sible with set_config function now.

Yeah you could do it safely with set_config and a CT= E, but suppose I have:

with a (Id, value) as (valu= es (1::Int, 'foo'), (2, 'bar'), (3, 'baz'))
SELECT set_config('custom_val', value) from a where id =3D 2;

What is the result out of this?=C2=A0 I would *expec= t* that this would probably run set_config 3 times and filter the output.
=C2=A0
<= div class=3D"gmail_extra">

Re= gards

Pavel


=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

regards

Pavel
<= div>


<= /font>
=



--
Best Regards,
Chris Travers
Database Administrator


=




--
Best Regards,
Chris Travers
<= div>Database Administrator

Tel:=C2=A0+49 162 9037 210=C2=A0| Skype: einhverfr |=C2=A0www.adjust.com=C2= =A0
Saarbr=C3=BCcker Stra=C3=9Fe 37a, 10405 Berlin

--94eb2c083c6a2079f5055caba49a--