Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id CAFj8pRD6x=-i50ZNtFu2RX8d3BSMnDr2L+QDsmEYoLchwVgb+Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers


2017-01-10 7:31 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:

Hello Robert,

Half-persistence (in definition, not in value) is not a key feature needed by the use-case.

Well, you don't get to decide that.

I do not think that your reprimand is deserved about this point: I did not decide a subjective opinion, I noted an objective fact.

You've been told by at least three or four people that they don't want variables to be transactional, you've been pointed to documentation links showing that in other database systems including Oracle variables are not transactional, and you still insist that this proposal is senseless unless variables are transactional.

Indeed.

I have submitted a proof of this fact in the form of a counter example which (1) (pseudo) implements the use-case by logging into an audit table the fact a user accesses the secure level (2) shows that the status of a non transactional session variable used for keeping this status is wrong for the use case in some cases (it says that all is well while appending to the audit table failed).

I have also recognized that the use-case could be implemented safely, although not correctly, if pg provides nested/autonomous transactions like Oracle, DB2 or MS SQL does, but I think that having such a useful feature is quite far away...

You have every right to decide what you think is useful, but you don't have a right to decide what other people think is useful.

Hmmm.

I feel entitled to point out to other people that their belief that a feature as described provides a correct solution to a particular use case is wrong, if it is factually the case. If they persist in this belief despite the submitted proof, I can only be sad about it, because if pg provides a feature for a security-relared use case which does not work correctly it is just shooting one's foot.

I do not like Pavel's feature, this is a subjective opinion. This feature does not provide a correct solution for the use case, this is an objective fact. The presented feature does not have a real use case, this is too bad.

I wrote more time, so transactional and temporal support can be optional feature. The people who uses package or module variables in other RDBMS probably doesn't agree with you, so there are not real use case.

The transaction support is not main point in my proposal - the main points are:

1. catalog based - created only once time, persistent metadata
2. allows be schema organized - like our PL functions
3. disallow identifier conflict - the name is unique in catalogue
4. allows to use declared secure access

After this discussion I append points

5. can be temporal - metadata are cleaned after end of life scope
6. can be transactional where content should be sensitive on possible rollback

Regards

Pavel
 

Finally, I did not "veto" this feature, I reviewed it in depth and concluded negatively. You are a committer and I'm just a "silly academic", you do not have to listen to anything I say and can take majority votes against proofs if you want.

--
Fabien.

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] pg_hba_file_settings view patch
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] sequence data type