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 without getter/setter functi
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 setter/
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 proposal.
>
> You do not
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 proposal.
>
> You do not
>
>
>
>
>>
>> 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 p
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 on
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 implementation of XA variable
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
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 proposal.
Perhaps this was not ad
There is a link - comparation Oracle package variables and DB2 global
variables
https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/
Regards
Pavel
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 get
>> firmer.
>> >
>> > My personal stance right now is that I'd like to se
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 catalog-decared
> typed
> > variables. I would prefer th
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 least oppose
> anything
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 against [Pavel's] propos
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 probabl
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 the
> containing transa
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 th
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
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
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 a non
> transactional
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 bad.
Oh, also, you mi
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 non
> transactional ses
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 point: I did not
> decide a
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 tol
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 with local temporary ta
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
transactional, you've be
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
https://www.postgresql.org/message-id/4b577e9f.8000...@dunslan
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 that it was also a (good) surprise for me.
>
> The documenta
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 feature. Editing config file i
>
>>
>> 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 agree
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 GUCs and allow them to be user
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 im
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 SET
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 can be extended inste
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 S
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.
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 equivalently SET SESSION) is issued
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=> SET x.s = 'x';
SET
craig=> BEGIN;
BEGIN
crai
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 reverted, whether you comm
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.
>
> Uh. I take that back.
>
> craig=> SET x.s = 'x
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 not
>>> be changed, it i
[...] 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 transactional
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 LOCAL which hides the pr
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.
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 fails and the second succ
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
> interesting feature t
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:
[...]
##
>
>> 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
>
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
connec
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 setting
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 AUTONOMOUS transactions, which
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 variable. If the variable is
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 transactio
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 sta
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
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 opinion and don't agree with i
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 unsafe package
> varia
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 reas
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 user-defined GUCs alread
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 mecanis
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 gmail client mask me thes
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 Arc
** 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
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 your design is unhapp
** 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;
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 running under only one tran
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 rollb
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" transactional property for
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.
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?
>>>
>>> Moreover, is there any
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 varia
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 n
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?
>
> Moreover, is there any actual
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 diff
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 sess
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, there is replication
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 definiti
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
> to setting user up but outside of this func
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
issue... whatever, a tra
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 to retype non trivial
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', 'some-oth
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 unescap
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
>> don't need to hide
>
> 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
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
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 st
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 deployment of secure
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.
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
> consultation) to
> > constant returning plpgsql func
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 security
> invoker, on
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 the proposal 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 fin
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 have not unique definit
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 and
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
>> >> static analysis of plpgsql using his plpgsql_check tool. So he wants
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
>>> achieve the static
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
you
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 something like Oracle's PL/SQL package
> variab
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 assu
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
> >> persistent definitions.
> >
> >
> > I've been in
1 - 100 of 189 matches
Mail list logo
