Re: [HACKERS] proposal: session server side variables
От | Craig Ringer |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables |
Дата | |
Msg-id | CAMsr+YGiyeritff_ck8nUBXtmJb1PwZGO8-itOrK0KZ_vJFE4w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [HACKERS] proposal: session server side variables
|
Список | pgsql-hackers |
On 30 December 2016 at 14:50, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > >>> I know this one. It can be empty, which a singleton cannot be. For a >>> singleton table, you should have one and only one row, you cannot insert or >>> delete, so this is only part of the real thing. >> >> >> Surely we can do a bit better than that, if that's what you really want. >> Create the table with an initial row and add a trigger preventing anything >> except update. > > > Yes. > > I just meant that this is not available easily "out of the box", but it is > obviously doable with some effort... which people would seldom do. Sure... but every feature has a cost too, in maintenance and reliability. This needs to have compelling use cases, and it's not free to add multiple similar-ish/overlapping features. So some agreement on what we should actually have is needed, along with a compelling case for what it delivers that we can't already do. Pavel's personal requirements include that it be well suited for static analysis of plpgsql using his plpgsql_check tool. So he wants persistent definitions. You expect different things from variables, to the point where it's a different feature. It's unlikely two unrelated variable implementations will be accepted. I think progress can only be achieved by setting out requirements, a feature matrix, and which proposed implementations can deliver which desired features. Then go from there. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: