Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Fabrízio de Royes Mello
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id CAFcNs+qv_4AinAtjWw+o9cMTeKmiVgEBvt0RNrZJoWdy2BSi9w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers

On Tue, Dec 27, 2016 at 6:55 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
> 2016-12-27 21:38 GMT+01:00 Fabrízio de Royes Mello <fabriziomello@gmail.com>:
>>
>>
>> On Fri, Dec 23, 2016 at 4:00 PM, Joe Conway <mail@joeconway.com> wrote:
>> >
>> > >> 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?).
>> > >
>> > > I have a plan to support TRANSACTION and SESSION scope. Persistent or
>> > > shared scope needs much more complex rules, and some specialized extensions
>> > > will be better.
>> >
>> >
>> > I can see where persistent variables would be very useful though.
>> >
>>
>> Can you talk more about your though??
>>
>> I'm thinking about PERSISTENT VARIABLES and maybe they can be the redesign of our hard coded "reloptions", with the ability to provide users to create their own customized. If we think more carefully we already have some persistent variables with specialized context: reloptions (hardcoded), security labels (local and shared catalog) and comments (local and shared catalog). I was clear enough?
>
>
> What is difference from table Values(keys varchar primary key, value text) ? Where is any benefit?
>

IMHO it's a totally different thing because with this approach we'll have:
- track dependency (aka pg_depend)
- different LockLevel for each persistent variable (reloption)
- syscache to improve performance

And It's a way to store metadata about metadata, i.e. property about our objects. This can be useful to:
- author extensions to store your own properties with each object
- postgres developers to have a simple way to add a new reloption just adding a new row to bootstrap data

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: [HACKERS] Some thoughts about multi-server sync rep configurations
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries