Re: Re: [HACKERS] proposal: schema variables

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: Re: [HACKERS] proposal: schema variables
Дата
Msg-id alpine.DEB.2.21.1903070853110.30581@lancre
обсуждение исходный текст
Ответ на Re: Re: [HACKERS] proposal: schema variables  (David Steele <david@pgmasters.net>)
Ответы Re: Re: [HACKERS] proposal: schema variables
Re: [HACKERS] proposal: schema variables
Список pgsql-hackers
Hello David,

> This patch hasn't receive any review in a while and I'm not sure if that's 
> because nobody is interested or the reviewers think it does not need any more 
> review.
>
> It seems to me that this patch as implemented does not quite satisfy any one.
>
> I think we need to hear something from the reviewers soon or I'll push this 
> patch to PG13 as Andres recommends [1].

I have discussed the feature extensively with Pavel on the initial thread.

My strong opinion based on the underlying use case is that it that such 
session variables should be transactional by default, and Pavel strong 
opinion is that they should not, to be closer to Oracle comparable 
feature.

According to the documentation, the current implementation does provide a 
transactional feature. However, it is not the default behavior, so I'm in 
disagreement on a key feature, although I do really appreciate that Pavel
implemented the transactional behavior.

Otherwise, ISTM that they could be named "SESSION VARIABLE" because the 
variable only exists in memory, in a session, and we could thing of adding 
other kind of variables later on.

I do intend to review it in depth when it is transactional by default.

Anyway, the patch is non trivial and very large, so targetting v12 now is 
indeed out of reach.

-- 
Fabien.


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
Следующее
От: David Steele
Дата:
Сообщение: Re: Re: Feature: triggers on materialized views