Re: RFC: Non-user-resettable SET SESSION AUTHORISATION

Поиск
Список
Период
Сортировка
От José Luis Tallón
Тема Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Дата
Msg-id 555B9E37.9060104@adv-solutions.net
обсуждение исходный текст
Ответ на Re: RFC: Non-user-resettable SET SESSION AUTHORISATION  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 05/19/2015 09:00 PM, Simon Riggs wrote:
[snip]

I think the idea of having SET SESSION AUTH pass a cookie, and only let
RESET SESSION AUTH work when the same cookie is supplied, is pretty
reasonable.

As long as the cookie is randomly generated for each use, then I don't see a practical problem with that approach.

Protocol level solution means we have to wait 1.5 years before anybody can begin using that. I'm also dubious that a small hole in the protocol arrangements could slam that door shut because we couldn't easily backpatch.

Having an in-core pooler would be just wonderful because then we could more easily trust it and we wouldn't need to worry.

Ufff.... Please don't do that.
Postgres is "just" a database. And a very good one at that. Let us keep it that way and not try to re-implement everything within it --- We're not "the big red company" after all :)

There are places where a pooler is badly needed.... and others where it is just overkill and counterproductive.
Plus, scalability models / usage patterns are not nearly the same (nor even compatible sometimes!) between databases and poolers.


There exist perfectly good solutions already (and they can certainly be improved), such as PgBouncer (or even PgPool-II) or others can be adopted.


Just my .02€


    / J.L.


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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Per row status during INSERT .. ON CONFLICT UPDATE?
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Problems with question marks in operators (JDBC, ECPG, ...)