Re: [HACKERS] proposal: session server side variables

2017-02-06 21:36 GMT+01:00 Fabien COELHO : > > Hello, > > I'll work on my proposal in v11 time. Maybe in this time Postgres will >> support autonomous transactions. >> > > Maybe. > > The variables syntax should be better integrated to core - it should be >> implemented

Re: [HACKERS] proposal: session server side variables

Hello, I'll work on my proposal in v11 time. Maybe in this time Postgres will support autonomous transactions. Maybe. The variables syntax should be better integrated to core - it should be implemented without getter/setter functions. Yes, a nicer syntax would be great. Note that

Re: [HACKERS] proposal: session server side variables

2017-02-03 11:18 GMT+01:00 Fabien COELHO : > > We can implement XA support for variables, ale I don't think so default >> should be XA. >> > > I was answering your question, which is what you can do about the > feedback: take the one hard/strong point into account in your

Re: [HACKERS] proposal: session server side variables

2017-02-03 11:18 GMT+01:00 Fabien COELHO : > > We can implement XA support for variables, ale I don't think so default >> should be XA. >> > > I was answering your question, which is what you can do about the > feedback: take the one hard/strong point into account in your

Re: [HACKERS] proposal: session server side variables

> > > > >> >> My "hard" opinion is that providing an unsafe by default feature (i.e. >> which works as in some particular cases, but may fail silently if the >> transaction fails), especially for a security related use case which >> motivates the whole feature addition, is a very bad idea for the

Re: [HACKERS] proposal: session server side variables

We can implement XA support for variables, ale I don't think so default should be XA. I was answering your question, which is what you can do about the feedback: take the one hard/strong point into account in your proposal. You do not want to do that. Too bad. The argument that you keep

Re: [HACKERS] proposal: session server side variables

2017-02-03 7:25 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > The @1 area is partially solved by psql session variables or by pgAdmin >> scripting functionality. @2 is partially solved by GUC but without >> possibility to set a access rights. >> >> I didn't found any

Re: [HACKERS] proposal: session server side variables

Hello Pavel, The @1 area is partially solved by psql session variables or by pgAdmin scripting functionality. @2 is partially solved by GUC but without possibility to set a access rights. I didn't found any implementation of XA variables [...] I did: GUCs in PostgreSQL are an implementation

Re: [HACKERS] proposal: session server side variables

On Fri, Feb 3, 2017 at 2:56 PM, Pavel Stehule wrote: > My patch was marked as "returned with feedback". Personally, I had not a > idea what can be next step and what is preferred design, if some preferred > design exists. I don't know what I have to change on my

Re: [HACKERS] proposal: session server side variables

There is a link - comparation Oracle package variables and DB2 global variables https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/ Regards Pavel

Re: [HACKERS] proposal: session server side variables

2017-02-01 6:42 GMT+01:00 Pavel Stehule : > > > 2017-02-01 6:05 GMT+01:00 Michael Paquier : > >> On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer >> wrote: >> > There is no code yet. Code review and testing is where things

Re: [HACKERS] proposal: session server side variables

2017-02-01 6:05 GMT+01:00 Michael Paquier : > On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer > wrote: > > There is no code yet. Code review and testing is where things get firmer. > > > > My personal stance right now is that I'd like to see

Re: [HACKERS] proposal: session server side variables

On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer wrote: > There is no code yet. Code review and testing is where things get firmer. > > My personal stance right now is that I'd like to see catalog-decared typed > variables. I would prefer them to be transactional and would at

Re: [HACKERS] proposal: session server side variables

On 11 Jan. 2017 16:29, "Fabien COELHO" wrote: > I'm lost. This is precisely what I had in mind above with "read-only transaction" which is "warranted not to fail". I do not understand about which point you write "No". I misread. We agree. >> Are you "voting" for or

Re: [HACKERS] proposal: session server side variables

Hello Craig. I'm not so sure about Craig precise opinion, but I cannot talk in his name. I think that I understood that he points out that there exists a situation where the use case is okay despite an untransactional variable: if the containing transaction is warranted not to fail, and

Re: [HACKERS] proposal: session server side variables

On 11 January 2017 at 06:09, Fabien COELHO wrote: > I'm not so sure about Craig precise opinion, but I cannot talk in his name. > I think that I understood that he points out that there exists a situation > where the use case is okay despite an untransactional variable: if

Re: [HACKERS] proposal: session server side variables

Hello Robert, You're just ignoring explanations from other people - Craig in particular - about why it DOES satisfy their use case. I'm not so sure about Craig precise opinion, but I cannot talk in his name. I think that I understood that he points out that there exists a situation where

Re: [HACKERS] proposal: session server side variables

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. Oh, also, you might want to tell Oracle and the many people who use

Re: [HACKERS] proposal: session server side variables

Hello Craig, 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

Re: [HACKERS] proposal: session server side variables

On Tue, Jan 10, 2017 at 1:31 AM, Fabien COELHO wrote: > 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

Re: [HACKERS] proposal: session server side variables

On 10 January 2017 at 14:31, Fabien COELHO wrote: > 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

Re: [HACKERS] proposal: session server side variables

On 10 January 2017 at 14:31, Fabien COELHO wrote: > 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

Re: [HACKERS] proposal: session server side variables

2017-01-10 7:31 GMT+01:00 Fabien COELHO : > > 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

Re: [HACKERS] proposal: session server side variables

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

Re: [HACKERS] proposal: session server side variables

On 10 January 2017 at 05:14, Robert Haas wrote: > 2. The user doesn't need to re-declare the variables you want to use > at the beginning of every session. This is also the reason why many > people want global temporary tables. They don't do anything that > can't be done

Re: [HACKERS] proposal: session server side variables

On Thu, Jan 5, 2017 at 5:39 AM, Fabien COELHO wrote: > 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. You've been told by at least three or four people that they don't want variables to be

Re: [HACKERS] proposal: session server side variables (fwd)

Hello Bruce, Good. So we seem to agree that GUCS are transactional? Uh, I think it is a missing feature, i.e.: https://wiki.postgresql.org/wiki/Todo#Administration Have custom variables be transaction-safe

Re: [HACKERS] proposal: session server side variables (fwd)

On Thu, Jan 5, 2017 at 11:45:24AM +0100, Fabien COELHO wrote: > > I must tweak my mail client configuration...> > > >>>Good. So we seem to agree that GUCS are transactional? > > > >I'm surprised, I never knew this. > > I must admit

Re: [HACKERS] proposal: session server side variables

2017-01-06 7:01 GMT+01:00 Pavel Stehule : > > >> >>> >>> Thank you for your work on this topic. >>> >>> Unfortunately, there is significant disagreement in this topic between >>> us. I see a schema based persistent metadata a catalog based security as >>> fundamental

Re: [HACKERS] proposal: session server side variables

> >> >> Thank you for your work on this topic. >> >> Unfortunately, there is significant disagreement in this topic between >> us. I see a schema based persistent metadata a catalog based security as >> fundamental feature. Editing config file is not acceptable in any view. >> > > I generally

Re: [HACKERS] proposal: session server side variables

On 6 January 2017 at 08:44, Jim Nasby wrote: >>(1) private/public visibility (as Oracle does with package vars). >>this point is enough to implement the presented use case. Agreed. >>(2) typing (casting is a pain) We already have typed

Re: [HACKERS] proposal: session server side variables

On 1/5/17 4:59 AM, Pavel Stehule wrote: - Personnaly, I'm not convinced that a NEW type of session variable is a good thing as pg already has one, and two is one too many. I would find it more useful to enhance existing dynamic session variables with, by order of

Re: [HACKERS] proposal: session server side variables

Good. So we seem to agree that GUCS are transactional? I'm surprised, I never knew this. I must admit that it was also a (good) surprise for me. The documentation says it: """ If SET (or equivalently SET SESSION) is issued within a transaction that is later aborted, the effects of the

Re: [HACKERS] proposal: session server side variables

2017-01-05 11:39 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > There are more reasons, why I would not to use GUC >> > > 0. it is not designed be secure - there is different security model - >> readonly, superuser, others >> > > Sure, GUCs as is are not enough, but the model

Re: [HACKERS] proposal: session server side variables (fwd)

Good. So we seem to agree that GUCS are transactional? I'm surprised, I never knew this. I must admit that it was also a (good) surprise for me. The documentation says it: """ If SET

Re: [HACKERS] proposal: session server side variables

Hello Pavel, There are more reasons, why I would not to use GUC 0. it is not designed be secure - there is different security model - readonly, superuser, others Sure, GUCs as is are not enough, but the model can be extended instead of re-inventing the wheel with a new kind of variable.

Re: [HACKERS] proposal: session server side variables

2017-01-05 10:59 GMT+01:00 Fabien COELHO : > > Good. So we seem to agree that GUCS are transactional? >>> >> I'm surprised, I never knew this. >> > > I must admit that it was also a (good) surprise for me. > > The documentation says it: > > """ > If SET (or

Re: [HACKERS] proposal: session server side variables

On 5 January 2017 at 08:35, Craig Ringer wrote: > On 5 January 2017 at 01:49, Fabien COELHO wrote: >> >>> ok understand >> >> >> Good. So we seem to agree that GUCS are transactional? > > No. We don't agree. They aren't. Uh. I take that back. craig=>

Re: [HACKERS] proposal: session server side variables

On 5 January 2017 at 01:49, Fabien COELHO wrote: > >> ok understand > > > Good. So we seem to agree that GUCS are transactional? No. We don't agree. They aren't. The effects of SET LOCAL are reverted whether you commit or rollback. The effects of SET SESSION are never

Re: [HACKERS] proposal: session server side variables

On 01/04/2017 04:36 PM, Craig Ringer wrote: > On 5 January 2017 at 08:35, Craig Ringer wrote: >> On 5 January 2017 at 01:49, Fabien COELHO wrote: >>> Good. So we seem to agree that GUCS are transactional? >> >> No. We don't agree. They aren't. > >

Re: [HACKERS] proposal: session server side variables

2017-01-04 19:56 GMT+01:00 Fabien COELHO : > > [...] It is on critical path, so every check increase computer time for >> transaction end. >> > > Hmmm... Everything executed is on the critical path... > > It is a very good thing that GUCs are transactional, and this should

Re: [HACKERS] proposal: session server side variables

[...] It is on critical path, so every check increase computer time for transaction end. Hmmm... Everything executed is on the critical path... It is a very good thing that GUCs are transactional, and this should not be changed, it is a useful feature! Much more useful than non

Re: [HACKERS] proposal: session server side variables

2017-01-04 18:49 GMT+01:00 Fabien COELHO : > > ok understand >> > > Good. So we seem to agree that GUCS are transactional? > > The logic depends on transactions and on nesting level (nesting doesn't >> depends on transactions only) >> > > Yep, it probably also happens with

Re: [HACKERS] proposal: session server side variables

ok understand Good. So we seem to agree that GUCS are transactional? The logic depends on transactions and on nesting level (nesting doesn't depends on transactions only) Yep, it probably also happens with LOCAL which hides the previous value and restores the initial one when exiting.

Re: [HACKERS] proposal: session server side variables

2017-01-04 17:58 GMT+01:00 Fabien COELHO : > > See attached scripts for instance. >>> >> >> Your test shows so SET SESSION has not transactional behaviour - the >> transactions fails, but the value is not reverted to NULL. >> > > There are *two* function calls, the first

Re: [HACKERS] proposal: session server side variables

2017-01-04 17:30 GMT+01:00 Fabien COELHO : > > > Now we can this feature emulate with dblink, and there are patches in >> commitfest based on background workers, and emulation will be cheaper. >> > > I had not noticed that "background session" proposal. That's definitely an >

Re: [HACKERS] proposal: session server side variables

See attached scripts for instance. Your test shows so SET SESSION has not transactional behaviour - the transactions fails, but the value is not reverted to NULL. There are *two* function calls, the first fails and the second succeeds. Here is the trace with a some comments: [...] ##

Re: [HACKERS] proposal: session server side variables

> >> Um, what? No, not at all. >> >> GUCs are scoped, but not transactional, [...] >> > > The documentation is very scarse, so I have tested it. > > All tests I have done with commit & rollback on session variables (SET > SESSION) have shown a clean transactional behavior, with the value reverted

Re: [HACKERS] proposal: session server side variables

Now we can this feature emulate with dblink, and there are patches in commitfest based on background workers, and emulation will be cheaper. I had not noticed that "background session" proposal. That's definitely an interesting feature to have for some use cases. Dblink implies a new

Re: [HACKERS] proposal: session server side variables

Hello, The security-related use-case you have presented stores the status of the verification in a variable. If the variable is untransactional, then it has been shown that the variable status > may say ok while the verification has really really failed. That's only a concern if the

Re: [HACKERS] proposal: session server side variables

2017-01-04 14:33 GMT+01:00 Fabien COELHO : > > An alternative is to implement sub (nested) transactions, like Oracle and >> MS SQL Server... but that would be quite some work. >> > > As a complement, a search showed that IBM DB2, cited as a reference by > Pavel, has

Re: [HACKERS] proposal: session server side variables

On 4 Jan. 2017 19:03, "Fabien COELHO" wrote: >>> I respect your opinion and don't agree with it. >> >> >> Yeah. I'm pretty overwhelmingly unconvinced too. > > I'm lost. > > The security-related use-case you have presented stores the status of the > verification in a

Re: [HACKERS] proposal: session server side variables

An alternative is to implement sub (nested) transactions, like Oracle and MS SQL Server... but that would be quite some work. As a complement, a search showed that IBM DB2, cited as a reference by Pavel, has AUTONOMOUS transactions, which looks pretty much the same thing as nested

Re: [HACKERS] proposal: session server side variables

I respect your opinion and don't agree with it. Yeah. I'm pretty overwhelmingly unconvinced too. I'm lost. The security-related use-case you have presented stores the status of the verification in a variable. If the variable is untransactional, then it has been shown that the variable

Re: [HACKERS] proposal: session server side variables

Hello, I'm not sure I understand your point. If Oracle provides unsafe package variables that can fool auditors, it is not a sufficient reason for Pg to provide the same doubtful feature. And if they have sub-transactions then their feature may not necessarily be unsafe, at least if the coding

Re: [HACKERS] proposal: session server side variables

On 4 January 2017 at 17:31, Pavel Stehule wrote: >> I have also updated and simplified the "simple session variable" >> description, because now I'm convinced that they must be transactional, and >> that a distinct declaration statement is a pain. > > I respect your

Re: [HACKERS] proposal: session server side variables

2017-01-04 9:56 GMT+01:00 Fabien COELHO : > > With respect, I don't share your opinion - it is not enough for usage like >> package variables - there usually should not to use any dependency on >> transactions. >> > > I'm not sure I understand your point. If Oracle provides

Re: [HACKERS] proposal: session server side variables

With respect, I don't share your opinion - it is not enough for usage like package variables - there usually should not to use any dependency on transactions. I'm not sure I understand your point. If Oracle provides unsafe package variables that can fool auditors, it is not a sufficient

Re: [HACKERS] proposal: session server side variables

2017-01-03 20:56 GMT+01:00 Fabien COELHO : > > Hello, > > Probably there is not big difference between RESET and UNDO in complexity >> of implementation. You have to do partial implementation of MVCC. No >> simple >> code. >> > > I think so; yes; indeed. > > Also note that

Re: [HACKERS] proposal: session server side variables

Hello, Probably there is not big difference between RESET and UNDO in complexity of implementation. You have to do partial implementation of MVCC. No simple code. I think so; yes; indeed. Also note that user-defined GUCs already implements the transactional property, so probably the

Re: [HACKERS] proposal: session server side variables

2017-01-03 18:52 GMT+01:00 Fabien COELHO : > > ** PLEASE ** >>> COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN >>> REPLYING IN THE THREAD? >>> ** THANKS ** >> >> > Hmmm. It seems that you can't. You should, really. I am sorry - The

Re: [HACKERS] proposal: session server side variables

On 1/3/17 10:33 AM, Fabien COELHO wrote: ** PLEASE ** COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN REPLYING IN THE THREAD? ** THANKS ** +1. Frankly, I've been skipping most of your (Pavel) replies in this thread because of this. -- Jim Nasby, Data

Re: [HACKERS] proposal: session server side variables

** PLEASE ** COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN REPLYING IN THE THREAD? ** THANKS ** Hmmm. It seems that you can't. You should, really. If you use patterns that I wrote - the security context will be valid always. No: This pattern assumes

Re: [HACKERS] proposal: session server side variables

2017-01-03 17:33 GMT+01:00 Fabien COELHO : > > ** PLEASE ** > > COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN > REPLYING IN THE THREAD? > > ** THANKS ** > > [...] Then B believes that A succeeded, which is not the case. >>> >> >> No, just

Re: [HACKERS] proposal: session server side variables

** PLEASE ** COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN REPLYING IN THE THREAD? ** THANKS ** [...] Then B believes that A succeeded, which is not the case. No, just your design is unhappy SELECT A(..) SET SESSION VARIABLE status_ok = false;

Re: [HACKERS] proposal: session server side variables

2017-01-03 15:40 GMT+01:00 Fabien COELHO : > > Hello again, > > *** PLEASE, could you remove the parts of emails you are not responding to > when replying in the thread? THANKS. *** > > [...] Did I understand? >>> >> > I guess that the answer is "no":-) > > When you are

Re: [HACKERS] proposal: session server side variables

Hello again, *** PLEASE, could you remove the parts of emails you are not responding to when replying in the thread? THANKS. *** [...] Did I understand? I guess that the answer is "no":-) When you are running under only one transaction, then you don't need to solve reset variables on

Re: [HACKERS] proposal: session server side variables

2017-01-03 13:03 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > PLEASE, could you remove the parts of emails you are not responding to > when replying in the thread? THANKS. > > The current status is that both proposals are useless because the use case > needs "some"

Re: [HACKERS] proposal: session server side variables

Hello Pavel, PLEASE, could you remove the parts of emails you are not responding to when replying in the thread? THANKS. The current status is that both proposals are useless because the use case needs "some" transactional property for security. But probably some improvements are possible.

Re: [HACKERS] proposal: session server side variables

2017-01-02 16:55 GMT+01:00 Fabien COELHO : > > Hello, > > In my proposal was support for transaction scope - ON COMMIT RESET clause should be ok >>> >>> Could you update the wiki, both the proposal and the use-case >>> implementation, to reflect this point? >>> >>>

Re: [HACKERS] proposal: session server side variables

Hello, In my proposal was support for transaction scope - ON COMMIT RESET clause should be ok Could you update the wiki, both the proposal and the use-case implementation, to reflect this point? Moreover, is there any actual use-case for non-transactional secure half-persistent session

Re: [HACKERS] proposal: session server side variables

Attention! rollback is significantly expensive than RESET. I'm quite unclear about the difference... Transactional for an unshared only-in-memory session object is probably easy to implement, no WAL is needed... So I do not see the difference you have to store previous value This does

Re: [HACKERS] proposal: session server side variables

2017-01-02 11:48 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > In my proposal was support for transaction scope - ON COMMIT RESET clause >> should be ok >> > > Could you update the wiki, both the proposal and the use-case > implementation, to reflect this point? > >

Re: [HACKERS] proposal: session server side variables

Yep, the variable value must be rolled back, I think. Attention! rollback is significantly expensive than RESET. I'm quite unclear about the difference... Transactional for an unshared only-in-memory session object is probably easy to implement, no WAL is needed... So I do not see the

Re: [HACKERS] proposal: session server side variables

Hello Pavel, In my proposal was support for transaction scope - ON COMMIT RESET clause should be ok Could you update the wiki, both the proposal and the use-case implementation, to reflect this point? Moreover, is there any actual use-case for non-transactional secure half-persistent

Re: [HACKERS] proposal: session server side variables

2017-01-02 10:39 GMT+01:00 Fabien COELHO : > > Hello Craig, > > What if setup_user() succeeds as a function but the transaction it belongs >>> to fails for some reason (eg deferred constraints, other operation related >>> to setting user up but outside of this function fails,

Re: [HACKERS] proposal: session server side variables

Hello Craig, What if setup_user() succeeds as a function but the transaction it belongs to fails for some reason (eg deferred constraints, other operation related to setting user up but outside of this function fails, there is replication issue... whatever, a transaction may fail by

Re: [HACKERS] proposal: session server side variables

2017-01-02 3:06 GMT+01:00 Craig Ringer : > > > On 1 Jan. 2017 20:03, "Fabien COELHO" wrote: > > > > What if setup_user() succeeds as a function but the transaction it belongs > to fails for some reason (eg deferred constraints, other operation related

Re: [HACKERS] proposal: session server side variables

On 1 Jan. 2017 20:03, "Fabien COELHO" wrote: What if setup_user() succeeds as a function but the transaction it belongs to fails for some reason (eg deferred constraints, other operation related to setting user up but outside of this function fails, there is replication

Re: [HACKERS] proposal: session server side variables

2017-01-01 11:28 GMT+01:00 Fabien COELHO : > > Hello Pavel, and Happy new year! > > (1) Having some kind of variable, especially in interactive mode, allows to >>> manipulate previous results and reuse them later, without having to > resort to repeated sub-queries or

Re: [HACKERS] proposal: session server side variables

Hello Craig, and happy new year, Someone asked me off-list what use cases such a thing would have, since it seems not to be spelled out very clearly in this discussion. I think we're all assuming knowledge here. So. * Session starts * app does SELECT setup_user('user-auth-key-data',

Re: [HACKERS] proposal: session server side variables

Hello Pavel, and Happy new year! (1) Having some kind of variable, especially in interactive mode, allows to manipulate previous results and reuse them later, without having to resort to repeated sub-queries or to retype non trivial values. Client side psql :-variables are untyped and

Re: [HACKERS] proposal: session server side variables

2016-12-31 18:46 GMT+01:00 Fabien COELHO : > >DROP VARIABLE super_secret; >>>CREATE VARIABLE super_secret ...; >>> >> >> But you don't do it in functions - these variables are persistent - you >> don't create it or drop inside functions. The content is secure, so you

Re: [HACKERS] proposal: session server side variables

> > If you do not have expectations, then all is fine. > > (1) Having some kind of variable, especially in interactive mode, allows to >>> manipulate previous results and reuse them later, without having to >>> resort >>> to repeated sub-queries or to retype non trivial values. >>> >>> Client side

Re: [HACKERS] proposal: session server side variables

DROP VARIABLE super_secret; CREATE VARIABLE super_secret ...; But you don't do it in functions - these variables are persistent - you don't create it or drop inside functions. The content is secure, so you don't need to hide this variable against other. ISTM that you are still missing

Re: [HACKERS] proposal: session server side variables

Hello Craig, As for "slow", I have just tested overheads with pgbench, comparing a direct arithmetic operation (as a proxy to a fast session variable consultation) to constant returning plpgsql functions with security definer and security invoker, on a direct socket connection, with prepared

Re: [HACKERS] proposal: session server side variables

2016-12-31 17:51 GMT+01:00 Fabien COELHO : > > unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is >>> no miracle. >>> >> >> No - metadata, in my design, are persistent - like tables - so you don't >> calculate so any functions can drop a variables. The

Re: [HACKERS] proposal: session server side variables

unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is no miracle. No - metadata, in my design, are persistent - like tables - so you don't calculate so any functions can drop a variables. The deployment of secure variables is same like table deployment. No dynamic there.

Re: [HACKERS] proposal: session server side variables

2016-12-31 1:16 GMT+01:00 Craig Ringer : > On 30 December 2016 at 21:00, Fabien COELHO wrote: > > > As for "slow", I have just tested overheads with pgbench, comparing a > direct > > arithmetic operation (as a proxy to a fast session variable >

Re: [HACKERS] proposal: session server side variables

On 30 December 2016 at 21:00, Fabien COELHO wrote: > As for "slow", I have just tested overheads with pgbench, comparing a direct > arithmetic operation (as a proxy to a fast session variable consultation) to > constant returning plpgsql functions with security definer and

Re: [HACKERS] proposal: session server side variables

2016-12-30 18:39 GMT+01:00 Fabien COELHO : > > DECLARE @var EXTERNAL >>> >>> I do not know what you mean by 'EXTERNAL'. >>> >> >> it means "used as shared in session" >> > > Shared by whom? There is no such thing in the proposal I have made on the > wiki or in mails. In

Re: [HACKERS] proposal: session server side variables

DECLARE @var EXTERNAL I do not know what you mean by 'EXTERNAL'. it means "used as shared in session" Shared by whom? There is no such thing in the proposal I have made on the wiki or in mails. In the proposal variables are private to the role which creates them. It is possible to

Re: [HACKERS] proposal: session server side variables

2016-12-30 15:34 GMT+01:00 Fabien COELHO : > > Hello again, > > So any dynamic created object and related operations are not checkable by >>> plpgsql_check (or any tool). >>> >>> NO. Your first sentence does not imply this very general statement. >>> >> >> If you

Re: [HACKERS] proposal: session server side variables

Hello again, So any dynamic created object and related operations are not checkable by plpgsql_check (or any tool). NO. Your first sentence does not imply this very general statement. If you have not unique definition, you cannot to it. There is not possibility different between typo

Re: [HACKERS] proposal: session server side variables

2016-12-30 12:01 GMT+01:00 Pavel Stehule : > > > 2016-12-30 10:29 GMT+01:00 Craig Ringer : > >> On 30 December 2016 at 16:46, Fabien COELHO wrote: >> > >> >> Pavel's personal requirements include that it be well suited for >>

Re: [HACKERS] proposal: session server side variables

2016-12-30 14:45 GMT+01:00 Fabien COELHO : > > Please Pavel, could you avoid citing a whole long mail just for commenting > one point? > > * Why is it so necessary for plpgsql variables to be implemented as >>> persistent entities that are in the catalogs in order for you to

Re: [HACKERS] proposal: session server side variables

Please Pavel, could you avoid citing a whole long mail just for commenting one point? * Why is it so necessary for plpgsql variables to be implemented as persistent entities that are in the catalogs in order for you to achieve the static checking you want to? Is this due to limitations of

Re: [HACKERS] proposal: session server side variables

2016-12-30 11:03 GMT+01:00 Craig Ringer : > 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

Re: [HACKERS] proposal: session server side variables

Hello Craig, A long mail with many questions, that I tried to answered clearly, the result is too long... [...] I have no opinion here, as I've not seen plpgsql_check nor do I understand the issues Pavel perceives with having dynamic definitions of variables. I understand that Pavel

Re: [HACKERS] proposal: session server side variables

2016-12-30 10:29 GMT+01:00 Craig Ringer : > 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 > >>

  1   2   >