On 30 December 2016 at 17:29, Craig Ringer wrote:
> So lets take a step back or eight and ask "why?"
Oh, and speaking of, I see Pavel's approach as looking for a
PostgreSQL-adapted way to do something like Oracle's PL/SQL package
variables. Right Pavel?
If so, their properties are, as far
On 30 December 2016 at 16:46, Fabien COELHO wrote:
>
>> 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.
>
>
> I've been in static analysis for the last 25 years, and the logic of thi
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.
I've been in static analysis for the last 25 years, and the logic of this
statement fails me.
Pavel wants that the plpgsql_check tool
On 30 December 2016 at 14:50, Fabien COELHO 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 t
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 in
Not sure if term "singleton" is valid in relation database.
The term is valid in mathematics: The relational model is an extension of
set theory, eg the algebra includes set operators such as union,
intersection, difference... In the set theory, a singleton designate is a
exactly-one-elemen
On 12/29/2016 02:23 PM, Fabien COELHO wrote:
There is a singleton table :)
create table foo(x integer unique not null default 1 check(x = 1), y
integer);
insert into foo(y) values(100);
analyze foo;
I know this one. It can be empty, which a singleton cannot be. For a
singleton table, yo
2016-12-29 20:23 GMT+01:00 Fabien COELHO :
>
> There is a singleton table :)
>>
>> create table foo(x integer unique not null default 1 check(x = 1), y
>> integer);
>> insert into foo(y) values(100);
>> analyze foo;
>>
>
> I know this one. It can be empty, which a singleton cannot be. For a
> sing
There is a singleton table :)
create table foo(x integer unique not null default 1 check(x = 1), y integer);
insert into foo(y) values(100);
analyze foo;
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 ins
Hello Pavel,
There are two concepts - both can be implemented, and used (can be used
together).
That is one point I would like to ascertain clearly and explicitely, so
having various designs side by side, eg in the wiki page, would help if
and where they interact.
The second point I am ke
2016-12-29 14:41 GMT+01:00 Pavel Stehule :
>
>
> 2016-12-29 14:25 GMT+01:00 Fabien COELHO :
>
>>
>> I newer talked about persistent data. I talked about persistent metadata.
>>>
>>
>> Sure, I finally understood that detail. Now if I hear "persistent
>> variable", I by default understand that both
2016-12-29 14:25 GMT+01:00 Fabien COELHO :
>
> I newer talked about persistent data. I talked about persistent metadata.
>>
>
> Sure, I finally understood that detail. Now if I hear "persistent
> variable", I by default understand that both metadata and data are
> persistent... It requires some ef
I newer talked about persistent data. I talked about persistent metadata.
Sure, I finally understood that detail. Now if I hear "persistent
variable", I by default understand that both metadata and data are
persistent... It requires some effort to understand the subtelty.
I really don't pr
2016-12-29 11:42 GMT+01:00 Fabien COELHO :
>
> yes, I'll do it.
>>>
>>
>> But I'll remove some strange ideas.
>>
>
> Why?
>
> I rather expect that you would comment that you find them strange and
> argue why: there is no reason to "remove" a concept idea as such at least
> early in a discussion pr
[Oops, resent, wrong from address, please accept my apologies]
Hello Pavel,
There are two concepts - both can be implemented, and used (can be used
together).
That is one point I would like to ascertain clearly and explicitely, so having
various designs side by side, eg in the wiki page, wo
yes, I'll do it.
But I'll remove some strange ideas.
Why?
I rather expect that you would comment that you find them strange and
argue why: there is no reason to "remove" a concept idea as such at least
early in a discussion process...
Why persistent variables?
Because *you* want pers
2016-12-29 10:32 GMT+01:00 Pavel Stehule :
>
>
> 2016-12-29 10:11 GMT+01:00 Fabien COELHO :
>
>>
>> There is big difference - you concept missing any safe point. You have to
>>> specify same information more times.
>>>
>>
>> Not necessarily, and if so maybe twice. I'm ok to recognize that it is a
2016-12-29 10:11 GMT+01:00 Fabien COELHO :
>
> There is big difference - you concept missing any safe point. You have to
>> specify same information more times.
>>
>
> Not necessarily, and if so maybe twice. I'm ok to recognize that it is a
> difference between both approaches, and an inconvenient
There is big difference - you concept missing any safe point. You have to
specify same information more times.
Not necessarily, and if so maybe twice. I'm ok to recognize that it is a
difference between both approaches, and an inconvenient of the one I'm
proposing. There also see inconvenien
2016-12-29 9:57 GMT+01:00 Fabien COELHO :
>
> Please, could you remove the part of the mail you are not responding to
> and just keep the relevant part?
>
> Whatever the features and syntax, you can always shoot yourself in the
>>> foot.
>>>
>>
>> I disagree
>>
>
> Hmmm... I have succeeded in shot
Please, could you remove the part of the mail you are not responding to
and just keep the relevant part?
Whatever the features and syntax, you can always shoot yourself in the
foot.
I disagree
Hmmm... I have succeeded in shotting myself in the foot with possibly
every feature of every la
2016-12-29 9:46 GMT+01:00 Fabien COELHO :
>
> CREATE FUNCTION setup_user(TEXT, TEXT)
>>> RETURNS BOOLEAN SECURITY DEFINER AS $$
>>>
>>
> CREATE FUNCTION isUserAuditor()
>>>RETURNS BOOLEAN SECURITY DEFINER AS $$
>>>
>>
>> so what is worse - I did one new entry in pg_class and one entry in
>>
CREATE FUNCTION setup_user(TEXT, TEXT)
RETURNS BOOLEAN SECURITY DEFINER AS $$
CREATE FUNCTION isUserAuditor()
RETURNS BOOLEAN SECURITY DEFINER AS $$
so what is worse - I did one new entry in pg_class and one entry in
pg_attributes. You wrote two entries in pg_proc function - more you h
2016-12-29 9:36 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> Hmmm... I know a little bit about that field, ISTM that you are speaking
>>> of the current capabilities of a particular static analysis tool, but I'm
>>> not sure that the tool capabilities could not be enhanced to manage more
>>> thi
Hello Pavel,
Hmmm... I know a little bit about that field, ISTM that you are speaking
of the current capabilities of a particular static analysis tool, but I'm
not sure that the tool capabilities could not be enhanced to manage more
things.
It cannot be - the static analyze is limited to func
Hello Jim,
Yes if the private variable should be accessed. If the variable is
private, then it is private and nothing is needed. Idem for public.
Why force the extra busywork? Just allow for them to be public.
There is no extra busywork, having possibly private session variables cost
nearl
2016-12-28 19:17 GMT+01:00 Jim Nasby :
> On 12/28/16 11:29 AM, Fabien COELHO wrote:
>
>>
>> Hello Jim,
>>
>> 1) Variables would be completely non-transactional. [...] A solution
>>> to this problem would be to provide a plpgsql equivalent to plperl or
>>> plpython's session hashes.
>>>
>>
>> That
On 12/28/2016 10:17 AM, Jim Nasby wrote:
> Then IMHO what needs to happen is to have a discussion on actual syntax
> instead of calling into question the value of the feature. Following
> this thread has been very painful because the communications have not
> been very clear. Focus on grammar would
On 12/28/16 11:29 AM, Fabien COELHO wrote:
Hello Jim,
1) Variables would be completely non-transactional. [...] A solution
to this problem would be to provide a plpgsql equivalent to plperl or
plpython's session hashes.
That is what I have in mind with "session variables" à la MS/MY SQL, but
2016-12-28 17:53 GMT+01:00 Jim Nasby :
> On 12/28/16 9:57 AM, Fabien COELHO wrote:
>
>> * Other later triggers, etc, also reference USER_IS_AUDITOR
>>>
>>
>> The variable is not directly referenced, one would have to call
>> isUserAuditor() to access the private session value, but then you can
>>
Hello Jim,
1) Variables would be completely non-transactional. [...] A solution to
this problem would be to provide a plpgsql equivalent to plperl or
plpython's session hashes.
That is what I have in mind with "session variables" à la MS/MY SQL, but
at the SQL level, not PL/pgSQL level.
2
On 12/28/16 9:57 AM, Fabien COELHO wrote:
* Other later triggers, etc, also reference USER_IS_AUDITOR
The variable is not directly referenced, one would have to call
isUserAuditor() to access the private session value, but then you can
GRANT/REVOKE whatever you want on the access function.
Wh
2016-12-28 16:57 GMT+01:00 Fabien COELHO :
>
> My 0.02€ to try to illustrate a possible private session variable based
> implementation for this use case:
>
> * Session starts
>>
>
> \c app
>
> * app does SELECT setup_user('user-auth-key-data', 'some-other-blob')
>>
>
> SELECT setup_user('fjshdfjk
My 0.02€ to try to illustrate a possible private session variable based
implementation for this use case:
* Session starts
\c app
* app does SELECT setup_user('user-auth-key-data', 'some-other-blob')
SELECT setup_user('fjshdfjkshfjks', 'jklfsjfklsjfk');
** setup_user is SECURITY DEFI
2016-12-28 16:42 GMT+01:00 Fabien COELHO :
>
> Hello,
>
> Why should they? If it is a session variable, being created when needed or
>>> used with the right type could be enough?
>>>
>>
>> You cannot to trust some fuzzy object - or you have to play hard game with
>> securing content - hashing, cod
Hello,
Why should they? If it is a session variable, being created when needed or
used with the right type could be enough?
You cannot to trust some fuzzy object - or you have to play hard game with
securing content - hashing, coding, decoding - it is slow, cpu intensive
I'm afraid that I d
On 28 December 2016 at 22:04, Pavel Stehule wrote:
> For security the variable should be persistent.
>
> If you would to do statical analyse (what you usually would), then variable
> should be persistent.
>
> Currently the big issue of plpgsql_check is work with temporary tables.
> Local objects
2016-12-28 15:38 GMT+01:00 Fabien COELHO :
>
> For security the variable should be persistent.
>>
>
> Why should they? If it is a session variable, being created when needed or
> used with the right type could be enough?
>
You cannot to trust some fuzzy object - or you have to play hard game with
For security the variable should be persistent.
Why should they? If it is a session variable, being created when needed or
used with the right type could be enough?
If you would to do statical analyse (what you usually would), then variable
should be persistent.
I do not understand what
Also, I'm not yet convinced that simple privatizable transcient/session
variables would not be enough to fit the use case, [...]
So... maybe? The main question then becomes how you integrate access control.
For what it's worth, permissions on persistent functions could be used to
control a
2016-12-28 15:00 GMT+01:00 Craig Ringer :
> On 28 December 2016 at 21:19, Fabien COELHO wrote:
>
> > Also, I'm not yet convinced that simple privatizable transcient/session
> > variables would not be enough to fit the use case, so that for the same
> > price there would be session variables for a
On 28 December 2016 at 21:19, Fabien COELHO wrote:
> Also, I'm not yet convinced that simple privatizable transcient/session
> variables would not be enough to fit the use case, so that for the same
> price there would be session variables for all, not only special ones with
> permissions.
Since
2016-12-28 4:40 GMT+01:00 Craig Ringer :
> Fabien, I don't really see the point of "persistent variables". What
> benefit do they add over relations?
>
> You can add a simple function to fetch a tuple if you want it not to
> look like a subquery. Do it with heap access in C if you like, save
> the
2016-12-28 14:19 GMT+01:00 Fabien COELHO :
>
> Hello Craig,
>
> Fabien, I don't really see the point of "persistent variables". What
>> benefit do they add over relations?
>>
>
> A relation is a set of values, a variable is a scalar with one value.
>
> It is always possible to declare a set and us
Hello Craig,
Fabien, I don't really see the point of "persistent variables". What
benefit do they add over relations?
A relation is a set of values, a variable is a scalar with one value.
It is always possible to declare a set and use it as a singleton, but
somehow it seems cleaner to ask f
Fabien, I don't really see the point of "persistent variables". What
benefit do they add over relations?
You can add a simple function to fetch a tuple if you want it not to
look like a subquery. Do it with heap access in C if you like, save
the (trivial) planning costs.
I do see value to two di
On Tue, Dec 27, 2016 at 6:55 PM, Pavel Stehule
wrote:
>
>
> 2016-12-27 21:38 GMT+01:00 Fabrízio de Royes Mello <
fabriziome...@gmail.com>:
>>
>>
>> On Fri, Dec 23, 2016 at 4:00 PM, Joe Conway wrote:
>> >
>> > >> In the long term, What would be the possible scopes?
>> > >>
>> > >> TRANSACTION, SES
2016-12-27 21:38 GMT+01:00 Fabrízio de Royes Mello
:
>
> On Fri, Dec 23, 2016 at 4:00 PM, Joe Conway wrote:
> >
> > >> In the long term, What would be the possible scopes?
> > >>
> > >> TRANSACTION, SESSION, PERSISTANT ?
> > >>
> > >> Would some scopes orthogonal (eg SHARED between sessions for
On Fri, Dec 23, 2016 at 4:00 PM, Joe Conway 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 hav
2016-12-26 19:13 GMT+01:00 Pavel Stehule :
>
>
> 2016-12-26 18:20 GMT+01:00 Fabien COELHO :
>
>>
>>
>>
>> And how would it interact with some "fully persistent/shared" variables?
>>
>>
>>
>> I have not any use case for this. I don't know about any similar feature
>> in other database systems. Orac
2016-12-26 18:20 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> I don't understand to "expensive" word.
>>
>
> Hmmm...
>
> How much often you create/drop these variables?
>>
>
> Hmmm... As for "session variables" à la MY/MS-SQL, ISTM that a variable is
> "created" each time it is asked for, and it
Hello Pavel,
I don't understand to "expensive" word.
Hmmm...
How much often you create/drop these variables?
Hmmm... As for "session variables" à la MY/MS-SQL, ISTM that a variable is
"created" each time it is asked for, and it disappears completely at the
end of the session... So you c
2016-12-26 17:33 GMT+01:00 Fabien COELHO :
>
> please, can send link?
>>
>
> My badly interpreted PL/SQL example was on the same page you point to
> below:
>
> so some better documentation
>> https://docs.oracle.com/cd/E11882_01/appdev.112/e25519/packa
>> ges.htm#LNPLS99926
>>
>
> There is a priva
please, can send link?
My badly interpreted PL/SQL example was on the same page you point to
below:
so some better documentation
https://docs.oracle.com/cd/E11882_01/appdev.112/e25519/packages.htm#LNPLS99926
There is a private 'number_hired' which given its name I thought was
counting t
2016-12-26 17:15 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> SET ROLE Admin;
>>> DECLARE @secure_variable INTEGER RESTRICT; -- only accessible to Admin
>>>
>>
> Why introduce another security system?
>>
>
> That is a good question.
>
> I would prefer to avoid it and just have simple session
Hello Pavel,
SET ROLE Admin;
DECLARE @secure_variable INTEGER RESTRICT; -- only accessible to Admin
Why introduce another security system?
That is a good question.
I would prefer to avoid it and just have simple session variables... but
this is not what you want, so I'm trying to fin
2016-12-26 15:53 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> AFAICS they are shared between backends, [...] They constitute a
>>> consistent design.
>>>
>>
>> no
>> http://stackoverflow.com/questions/2383061/scope-of-oracle-
>> package-level-variables
>>
>
> If stackoverflow says so, too bad fo
Hello Pavel,
AFAICS they are shared between backends, [...] They constitute a
consistent design.
no
http://stackoverflow.com/questions/2383061/scope-of-oracle-package-level-variables
If stackoverflow says so, too bad for me:-) Now I do not understand the
point of the example I read on Orac
>
>> A possible compromise I have proposed is to have some declared access
>> restrictions on simple session variables, so that say only the owner can
>> access it, but they should stay and look like light-weight session
>> variables nevertheless. That could look like:
>>
>> SET ROLE Admin;
>>
2016-12-26 13:08 GMT+01:00 Fabien COELHO :
>
>
> Hello Pavel,
>
> you are talk about light session variables like MSSQL or MySQL (with same
>> syntax), I am talking about secure session variables like Oracle package
>> variables (with similar access syntax).
>>
>
> Hmmm. I do not know this Oracle
Hello Pavel,
you are talk about light session variables like MSSQL or MySQL (with same
syntax), I am talking about secure session variables like Oracle package
variables (with similar access syntax).
Hmmm. I do not know this Oracle stuff... After looking at the online
documentation, my unde
2016-12-26 10:54 GMT+01:00 Pavel Stehule :
> Hi
>
>
>>
>> In both case, the syntax should be nice and elegant... i.e. not only
>> based on functions, probably it should use some prefix convention (@, $)...
>> For the light weight option.
>>
>> DECLARE @someday DATE [ = ] [visibility restriction
Hi
>
> In both case, the syntax should be nice and elegant... i.e. not only based
> on functions, probably it should use some prefix convention (@, $)...
> For the light weight option.
>
> DECLARE @someday DATE [ = ] [visibility restriction?];
> ... then use @now as a possible value anywhere
Hello Pavel,
On Sat, 24 Dec 2016, Pavel Stehule wrote:
Maybe you could consider removing the part of the message that you are not
responding to, so that it would be easier for the reader to see your
answers and comments.
Hmmm. So I understand that you would like to do something like:
-
2016-12-26 8:30 GMT+01:00 Fabien COELHO :
>
> Hello Jim,
>
> If you want to ignore performance, there are things you can do with
>> non-transactional variables that are simply not possible with tables. But
>> even ignoring that, the performance cost of temp tables is massive compared
>> to variabl
Hello Jim,
If you want to ignore performance, there are things you can do with
non-transactional variables that are simply not possible with tables. But
even ignoring that, the performance cost of temp tables is massive compared
to variables.
Ok, then read "variables are like tables" instea
2016-12-24 12:19 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> Hmmm. Switching role within a transaction. I never did need that... but
>>> that is a use case.
>>>
>>
>> Any application with security definer functions - depends on different
>> communities - it is used sometimes strongly.
>>
>
> Hm
Hello Pavel,
Hmmm. Switching role within a transaction. I never did need that... but
that is a use case.
Any application with security definer functions - depends on different
communities - it is used sometimes strongly.
Hmmm. So I understand that you would like to do something like:
- c
On 12/23/16 4:24 PM, Fabien COELHO wrote:
I think that a special purpose variable infrastructure implied by your
remark is just starting from the end point. The first three points seem
relevant too because they help focus on other issues.
If you want to ignore performance, there are things you
Hello Tom,
Hmmm. If a variable is implemented as a one row table, then constraints
are already available there, as well as grant & revoke, they can be any
type including composite, nearly nothing to implement to get...
A "one row" table would be a CREATE + one INSERT, UPDATE allowed, further
2016-12-23 19:28 GMT+01:00 Fabien COELHO :
>
> because MySQL variables are not declared - and allows assign everywhere -
>>
>
> Ok. I do not do MySQL.
>
> and MSSQL variables are not persistent.
>>
>
> Yep, but they might be?
>
> In one session you can use lot of roles - some code can be used for
Fabien COELHO writes:
>> In first iteration the constraint can be implemented with domains - but
>> there is not any break to implement constraints directly on variables.
> Hmmm. If a variable is implemented as a one row table, then constraints
> are already available there, as well as grant & r
because MySQL variables are not declared - and allows assign everywhere -
Ok. I do not do MySQL.
and MSSQL variables are not persistent.
Yep, but they might be?
In one session you can use lot of roles - some code can be used for
securing interactive work, some can be for securing some AP
On 12/23/2016 08:20 AM, Pavel Stehule wrote:
> 2016-12-23 16:27 GMT+01:00 Fabien COELHO:
>> I have often wished I had such a feature, psql client side :-variables are
>> just awful raw text things.
Agreed.
>> A few comments, mostly about the design:
>>
>> 1. persistent objects with temporal unsha
2016-12-23 18:46 GMT+01:00 Fabien COELHO :
>
> Hello,
>
> I little bit dislike this style - in my proposal the session variables are
>> very near to a sequences - and we have not any special symbols for
>> sequences.
>>
>
> Yep, but we do not need a syntax to reference a sequence either... it is
>
Hello,
I little bit dislike this style - in my proposal the session variables are
very near to a sequences - and we have not any special symbols for
sequences.
Yep, but we do not need a syntax to reference a sequence either... it is
automatic and usually hidden behind SERIAL. I know there is
2016-12-23 16:27 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> The session variables should be:
>>
>
> I have often wished I had such a feature, psql client side :-variables are
> just awful raw text things.
>
> A few comments, mostly about the design:
>
> 1. persistent objects with temporal unsh
Hello Pavel,
The session variables should be:
I have often wished I had such a feature, psql client side :-variables are
just awful raw text things.
A few comments, mostly about the design:
1. persistent objects with temporal unshared typed content. The life of
content should be limited
2016-12-15 15:36 GMT+01:00 Pavel Stehule :
> Hi
>
> Most important features:
>>>
>>> 1. the values are stored in native types
>>> 2. access to content is protected by ACL - like the content of tables
>>> 3. the content is not MVCC based - no any cost of UPDATE
>>> 4. simple API allows access to co
Hi
Most important features:
>>
>> 1. the values are stored in native types
>> 2. access to content is protected by ACL - like the content of tables
>> 3. the content is not MVCC based - no any cost of UPDATE
>> 4. simple API allows access to content of variables from any supported
>> environment.
Hi
2016-11-28 10:39 GMT+01:00 Artur Zakirov :
> On 28.11.2016 10:42, Pavel Stehule wrote:
>
>>
>> next update - setattr, getattr functions are working now
>>
>> notes, comments?
>>
>> Regards
>>
>> Pavel
>>
>>
> It is interesting!
>
> Do you have plans to support also table variables? For example
On 28.11.2016 10:42, Pavel Stehule wrote:
next update - setattr, getattr functions are working now
notes, comments?
Regards
Pavel
It is interesting!
Do you have plans to support also table variables? For example, like this:
create type composite_type_2 as (a int, b text);
create variable
Hi
2016-11-25 15:32 GMT+01:00 Pavel Stehule :
> Hi
>
> 2016-10-14 9:56 GMT+02:00 Craig Ringer :
>
>> On 14 October 2016 at 13:30, Pavel Stehule
>> wrote:
>> > Hi,
>> >
>> > long time I working on this topic. Session server side variables are one
>> > major missing feature in PLpgSQL. Now I hope,
On 14 October 2016 at 23:09, Pavel Stehule wrote:
>> but only within the session, right? You're not proposing some kind of
>> inter-backend IPC where one backend sets a session var and another
>> backend accesses it and sees the value set by the first session?
>
> In this moment I propose only lo
Hi
2016-10-14 9:56 GMT+02:00 Craig Ringer :
> On 14 October 2016 at 13:30, Pavel Stehule
> wrote:
> > Hi,
> >
> > long time I working on this topic. Session server side variables are one
> > major missing feature in PLpgSQL. Now I hope, I can summarize requests
> for
> > implementation in Postgr
2016-10-14 9:56 GMT+02:00 Craig Ringer :
> On 14 October 2016 at 13:30, Pavel Stehule
> wrote:
> > Hi,
> >
> > long time I working on this topic. Session server side variables are one
> > major missing feature in PLpgSQL. Now I hope, I can summarize requests
> for
> > implementation in Postgres:
Pavel Stehule wrote
> Session server side variables are one major missing feature in PLpgSQL.
I think this would also be useful outside of PL/pgSQL to support query level
variables similar to what SQL Server does.
--
View this message in context:
http://postgresql.nabble.com/proposal-sessio
On 14 October 2016 at 13:30, Pavel Stehule wrote:
> Hi,
>
> long time I working on this topic. Session server side variables are one
> major missing feature in PLpgSQL. Now I hope, I can summarize requests for
> implementation in Postgres:
+1
> 2. accessed with respecting access rights:
>
> GRAN
101 - 188 of 188 matches
Mail list logo
