MIME-Version: 1.0
References: <afb4e296d7ce57986f23bcfdee39b259b8f85f56.camel@cybertec.at>
 <CAFj8pRAjU-X6rEE9=1++PdtXOPc2uo=yu-tcFXByi-kN3B_7Vw@mail.gmail.com>
 <CAFj8pRC+hPCc2X88xC=pTJoqmVPApDsageZOMyqaxi5788WxHA@mail.gmail.com>
 <CAFj8pRDJ9cq00VYSHxs6LsoHNWjhYXyWWBtV6UgeWwhs0AHa9A@mail.gmail.com>
 <CAFj8pRBPXTcw_3fpKtgVthV2+9rZGhxitZ40DnAwCrK601TZZg@mail.gmail.com>
 <ndtfl4tsnpkb7m7hwvnmlpsascpgd3a7xvjmjhtxffsbrgygtm@4du6zsmnnwq5>
 <CAFj8pRAu4XvNCGu1751t=2YEqLqTjDA3FavMExm2S0KYQq=DdQ@mail.gmail.com>
 <CAFj8pRAsEoeZv0HEnA8CKgFKDSQ-wYw18Os1vdksWCV7ez2bVw@mail.gmail.com>
 <3chredgnjcmccym2kczawfih226b4ac6co7p6z4jeofevrcosi@mrsxkx2x2c65>
 <CAFj8pRBoWPDTOwn5FmMzc+1qiopw+N04U26nviOdF61fs8A2wQ@mail.gmail.com>
 <stckyvkl4yyzvgjsaawojs3xikke7mmds5bhv7l7qerclywywk@h4v4n43xm6u2>
In-Reply-To: <stckyvkl4yyzvgjsaawojs3xikke7mmds5bhv7l7qerclywywk@h4v4n43xm6u2>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Sat, 16 Nov 2024 15:34:58 +0100
Message-ID: 
 <CAFj8pRAX4Pmh_pNcOFF7r_hHkdDNnZ7iwEb_7JyxOzZ8ZrxpXA@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Erik Rijkers <er@xs4all.nl>,
	Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>,
	DUVAL REMI <REMI.DUVAL@cheops.fr>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000d42a4d0627089893"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRAX4Pmh_pNcOFF7r_hHkdDNnZ7iwEb_7JyxOzZ8ZrxpXA%40mail.gmail.com>
Precedence: bulk

--000000000000d42a4d0627089893
Content-Type: text/plain; charset="UTF-8"

Hi


> As a side note, I've recently caught myself thinking "it would be cool to
> have
> session variables here". The use case was preparing a policy for RLS,
> based on
> some session-level data set by an application. This session-level data is
> of a
> composite data type, so simple current_setting is cumbersome to use, and a
> temporary table will be dropped at the end, taking the policy with it due
> to
> the recorded dependency between them. Thus a session variable of some
> composite
> type sounds like a good fit.
>

yes, RLS support is one mentioned use case, and strong reason the access
rights are implemented there.

Regards

Pavel

--000000000000d42a4d0627089893
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><div>Hi</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
As a side note, I&#39;ve recently caught myself thinking &quot;it would be cool to have<br>
session variables here&quot;. The use case was preparing a policy for RLS, based on<br>
some session-level data set by an application. This session-level data is of a<br>
composite data type, so simple current_setting is cumbersome to use, and a<br>
temporary table will be dropped at the end, taking the policy with it due to<br>
the recorded dependency between them. Thus a session variable of some composite<br>
type sounds like a good fit.<br></blockquote><div><br></div><div>yes, RLS support is one mentioned use case, and strong reason the access rights are implemented there.</div><div><br></div><div>Regards</div><div><br></div><div>Pavel<br></div></div></div>

--000000000000d42a4d0627089893--