Re: [HACKERS] proposal: session server side variables
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables |
Дата | |
Msg-id | alpine.DEB.2.20.1701051059560.3661@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: session server side variables (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] proposal: session server side variables
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] proposal: session server side variables (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Hello Pavel, > There are more reasons, why I would not to use GUC > 0. it is not designed be secure - there is different security model - > readonly, superuser, others Sure, GUCs as is are not enough, but the model can be extended instead of re-inventing the wheel with a new kind of variable. > 1. it is dynamic - not persistent - cannot be used as package variables > simply Half-persistence (in definition, not in value) is not a key feature needed by the use-case. > 2. there is different placing - custom requires prefix - I prefer using our > schemas, because schemas are used in pg like packages in Oracle Idem. > 3. large number of GUC decrease performace of end of transactions, > subtransactions That is life. The presented use-case really needs only one variable. > 4. any RDBMS using untransactional variables - it should be default > optimized behave Hmmm. Untransactional variables do **NOT** fit the use case, it just works "sometimes", which is not acceptabe. I've spent too much time on reviewing this proposal. My conclusion is: - a clear use case linked to security setups has been presented which requires some kind of secure (i.e. with access control)session variables, currently not available in pg which has user-defined GUC which are dynamic, untyped (TEXT),public, transactional. - you have proposed a NEW kind of session variables which is: (1) statically typed, declared permanently in the catalog, in the schema/table namespace (2) values are session alive (3) untransactional, as you insist on that (your 4. above) (4) with permissions My feedback is that: - The proposed feature does not fit the presented use case it is intended for. There is no use case for untransactionalsecure session variables. The proposal should be amended so that the variables display by default sometransactional properties because it is required for correctly implementing the use case. - Personnaly, I'm not convinced that a NEW type of session variable is a good thing as pg already has one, and two isone too many. I would find it more useful to enhance existing dynamic session variables with, by order of importance: (1) private/public visibility (as Oracle does with package vars). this point is enough to implement the presenteduse case. (2) typing (casting is a pain) (3) improved syntax (set_config & current_setting is a pain) Eventually, unrelated to the use case, but in line with your motivations as I understand them: (4) add an option to make a GUC non transactional, iff there is a clear use case for that (maybe debug?). (5) have some "permanent" GUC type declarations (maybe editing the config file does that already, by the way?) -- Fabien.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Kuntal GhoshДата:
Сообщение: Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.
Следующее
От: Fabien COELHOДата:
Сообщение: Re: [HACKERS] proposal: session server side variables (fwd)