Re: [HACKERS] proposal: session server side variables
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] proposal: session server side variables |
| Дата | |
| Msg-id | CAFj8pRD2qvo4p1HiAXyM9h0U-NV2zFowDfA+R=pEyr+TrjtWaw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Ответы |
Re: [HACKERS] proposal: session server side variables
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Список | pgsql-hackers |
Hi
In both case, the syntax should be nice and elegant... i.e. not only based on functions, probably it should use some prefix convention (@, $)...
For the light weight option.
DECLARE @someday DATE [ = <SQL EXPRESSION> ] [visibility restriction?];
... then use @now as a possible value anywhere, which will be
substituted quite early in the execution process, before planning.
-- update a variable value:
[SET, ASSIGN, ... nothing?] @someday = <SQL EXPRESSION>;
Ok, that is basically more or less the mysql syntax, too bad, but I think it makes sense for a lightweight object which should not look like a database object at all to avoid confusion.
As far as implementation is concerned, I would use a TEXT to TEXT hash table, and implicit cast the result when substituting.
@var -> 'text value of var'::type_it_was_declared_with
We are talking about two different features (although the part of name can be same):
you are talk about light session variables like MSSQL or MySQL (with same syntax), I am talking about secure session variables like Oracle package variables (with similar access syntax).
Theoretically, there can be implemented both - but cannot be implemented together. Its are partially different features. My proposal is clearly related to analogy with Oracle package variables and should to help to people who does migration from Oracle, or who writing application in Oracle style - database first, almost logic in database.
I have two important reasons why I insist on pg_class base.
1. security .. it is really fundamental part
2. possibility to static check by plpgsql_check - without entry in pg_class (or other catalogue table) I have not any valid information about type, existence of any variable.
Although I am not supporter (due possible issues with plpgsql_checks) of MySQL or MSSQL style variables I am not strongly against this implementation with same syntax. But it is different feature, with different benefits and costs.
I didn't proposed the packages (and package variables) due issues in multilingual PostgreSQL environment and because it is redundant to PostgreSQL schemas. Instead I proposed >>secure global session variables<< (global like global temporary tables).
Currently light session variables can be implemented as not big extension. Secure session variables depends on pg_class internals.
I am not sure if we need a special symbols - it is traditional only. Set/Get functions can do same work - years we use same technique for sequences. Setter function is simply. Currently is impossible to write elegant getter function - because the analyzer has limited work with "any" returning functions.
Can be nice to have special hook for functions that returns "any" to push there some other external informations.
Regards
Pavel
--
Fabien.
В списке pgsql-hackers по дате отправления: