public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Chris Travers <chris.travers@adjust.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: proposal: schema variables
Date: Sun, 29 Oct 2017 09:51:55 +0100
Message-ID: <CAN-RpxA3rnL3z5c=HOnJ+7QNNYh0z1WhggEpo6PLdeXKDaA6+g@mail.gmail.com> (raw)
In-Reply-To: <CAFj8pRAizy8cFWhf-J9DK-_iZU=VqkwweWL_J9d8Nv2Zep+=Lg@mail.gmail.com>
References: <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
<CAN-RpxD0_PFcyM4Lj=a9eQ3MQEiw2_eZwK2peo73hMV0cABmTw@mail.gmail.com>
<CAFj8pRAizy8cFWhf-J9DK-_iZU=VqkwweWL_J9d8Nv2Zep+=Lg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Sat, Oct 28, 2017 at 4:56 PM, Pavel Stehule <pavel.stehule@gmail.com>
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 purposes.
> 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 = 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ücker Straße 37a, 10405 Berlin
>> <https://maps.google.com/?q=Saarbr%C3%BCcker+Stra%C3%9Fe+37a,+10405+Berlin&entry=gmail&source...;
>>
>>
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
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: chris.travers@adjust.com, pavel.stehule@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: proposal: schema variables
In-Reply-To: <CAN-RpxA3rnL3z5c=HOnJ+7QNNYh0z1WhggEpo6PLdeXKDaA6+g@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