From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2016-12-23 15:27:23 |
Message-ID: | alpine.DEB.2.20.1612231548410.3892@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Pavel,
> The session variables should be:
I have often wished I had such a feature, psql client side :-variables are
just awful raw text things.
A few comments, mostly about the design:
> 1. persistent objects with temporal unshared typed content. The life of
> content should be limited by session or by transaction. The content is
> initialized to default (when it is defined) or to NULL when variable is
> first accessed in variable' time scope (session, transaction).
>
> CREATE VARIABLE [schema.]variable type [DEFAULT default_value]
> [TRANSACTION|SESION SCOPE]
I'm not sure of the order, and from a parser perspective it is nice to
announce the type before the value.
Maybe a SQL-server like @-prefix would be nice, something like:
CREATE VARIABLE @foo TEXT DEFAULT 'hello' SCOPE SESSION;
> DROP VARIABLE [schema.]variable
In the long term, What would be the possible scopes?
TRANSACTION, SESSION, PERSISTANT ?
Would some scopes orthogonal (eg SHARED between sessions for a USER in a
DATABASE, SHARED at the cluster level?).
How to deal with namespace issues?
> 2. accessed with respecting access rights:
>
> GRANT SELECT|UPDATE|ALL ON VARIABLE variable TO role
> REVOKE SELECT|UPDATE|ALL ON VARIABLE variable FROM role
At least for transaction and session scopes it does not make sense that
they would be accessible outside the session/transaction, so grant/revoke
do not seem necessary?
> 3. accessed/updated with special function "getvar", "setvar":
>
> FUNCTION getvar(regclass) RETURNS type
> FUNCTION setvar(regclass, type) RETURNS void
From an aesthetical point of view, I do not like that much.
If you use CREATE & DROP, then logically you should use ALTER:
CREATE VARIABLE @name TEXT DEFAULT 'calvin';
CREATE VARIABLE @name TEXT = 'calvin';
ALTER VARIABLE @name SET VALUE TO 'hobbes';
ALTER VARIABLE @name = 'hoobes';
DROP VARIABLE @name;
Maybe "SET" could be an option as well, but it is less logical:
SET @name = 'susie';
But then "SET @..." would just be a shortcut for ALTER VARIABLE.
Also a nicer way to reference them would be great, like SQL server.
SELECT * FROM SomeTable WHERE name = @name;
A function may be called behind the scene, I'm just arguing about the
syntax here...
Important question, what nice syntax to assign the result of a query to a
variable? Maybe it could be:
SET @name = query-returning-one-row; -- hmmm
SET @name FROM query-returning-one-row; -- maybe better
Or:
ALTER VARIABLE @name WITH one-row-query;
Special variables could allow to get the number of rows modified by the
last option, like in PL/pgSQL but at the SQL level?
> 4. non transactional - the metadata are transactional, but the content is
> not.
Hmmm... Do you mean:
CREATE VARIABLE foo INT DEFAULT 1 SCOPE SESSION;
BEGIN;
SET @foo = 2;
ROLLBACK;
Then @foo is 2 despite the roolback? Yuk!
I think that if the implementation is based on some system table for
storage, then you could get the transaction properties for free, and it
seems more logical to do so:
CREATE TEMPORARY TABLE pg_session_variables(name TEXT PRIMARY KEY, value TEXT, oidtype, ...);
CREATE VARIABLE @foo INTEGER; -- INSERT INTO TABLE ...
SELECT * FROM x WHERE name = @foo;
-- SELECT * FROM x WHERE name = (SELECT value::INT FROM pg_session_variables WHERE name='foo')
So maybe some simple syntactic rewriting would be enough? Or some SPI
function?
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-12-23 16:03:44 | Re: Server Crash while running sqlsmith [TRAP: FailedAssertion("!(keylen < 64)", File: "hashfunc.c", Line: 139) ] |
Previous Message | Tom Lane | 2016-12-23 15:24:08 | Re: Remove lower limit on checkpoint_timeout? |