Re: [HACKERS] proposal: schema variables

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] proposal: schema variables
Дата
Msg-id CAKFQuwa00-4HTujbnYNy_OdZ2OfjUO3AX4R91DbQ1wPBZegCfg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: schema variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [HACKERS] proposal: schema variables
Список pgsql-hackers
Дерево обсуждения
​I've done a non-compilation documentation review, the diff from the poc patch and the diff from master are attached.

Comments are inter-twined in the patch in xml comment format; though I reiterate (some of?) them below.

On Fri, Feb 2, 2018 at 3:06 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi

I wrote proof concept of schema variables. The patch is not nice, but the functionality is almost complete (for scalars only) and can be good enough for playing with this concept.

I recap a goals (the order is random):

1. feature like PL/SQL package variables (with similar content life cycle)
2. available from any PL used by PostgreSQL, data can be shared between different PL
3. possibility to store short life data in fast secured storage

​The generic use of the word secure here bothers me.  I'm taking it to be "protected by grant/revoke"-based privileges; plus session-locality.

4. possibility to pass parameters and results to/from anonymous blocks
5. session variables with possibility to process static code check

What does "process static code check" means here?​
 
6. multiple API available from different environments - SQL commands, SQL functions, internal functions

I made the public aspect of this explicit in the CREATE VARIABLE doc (though as noted below it probably belongs in section II)
​
7. data are stored in binary form 

Thoughts during my review:

There is, for me, a cognitive dissonance between "schema variable" and "variable value" - I'm partial to the later.  Since we use "setting" for GUCs the term variable here hopefully wouldn't cause ambiguity...

I've noticed that we don't seem to have or enforce any policy on how to communicate "SQL standards compatibility" to the user...

We are missing the ability to alter ownership (or at least its undocumented), and if that brings into existing ALTER VARIABLE we should probably add ALTER TYPE TO new_type USING (cast) for completeness.

Its left for the reader to presume that because these are schema "relations" that namespace resolution via search_path works the same as any other relation.

I think I've answered my own question regarding DISCARD in that "variables" discards values while if TEMP is in effect all temp variables are dropped.

Examples abound though it doesn't feel like too much: but saying "The usage is very simple:" before giving the example in the function section seems to be outside of our general style.  A better preamble than "An example:" would be nice but the example is so simple I could not think of anything worth writing.

Its worth considering how both:

https://www.postgresql.org/docs/10/static/ddl.html
and 
https://www.postgresql.org/docs/10/static/queries.html

could be updated to incorporate the broad picture of schema variables, with examples, and leave the reference (SQL and functions) sections mainly relegated to syntax and reminders.

A moderate number of lines changed are for typos and minor grammar edits.

David J.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: ALTER TABLE ADD COLUMN fast default
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [HACKERS] Re: Improve OR conditions on joined columns (commonstar schema problem)