Hi
2016-02-23 20:52 GMT+01:00 Pavel Stehule :
>
>
> 2016-02-12 22:41 GMT+01:00 Jim Nasby :
>
>> On 2/12/16 2:58 PM, Pavel Stehule wrote:
>>
>>>
>>> So I think adding something like this needs to at least address
>>> *how* SQL level access would work, *when* it's eventually
>>> implemented
2016-02-12 22:41 GMT+01:00 Jim Nasby :
> On 2/12/16 2:58 PM, Pavel Stehule wrote:
>
>>
>> So I think adding something like this needs to at least address
>> *how* SQL level access would work, *when* it's eventually implemented.
>>
>>
>> I understand - and I agree.
>>
>> small note: Private
2016-02-12 22:41 GMT+01:00 Jim Nasby :
> On 2/12/16 2:58 PM, Pavel Stehule wrote:
>
>> I think that's probably true, but this also shows why we need to consider
>> different PLs too. As it stands right now, the only way to access a
>> variable outside of plpgsql would be to call a plpgsql function
On 2/12/16 2:58 PM, Pavel Stehule wrote:
So I think adding something like this needs to at least address
*how* SQL level access would work, *when* it's eventually implemented.
I understand - and I agree.
small note: Private variables should not be executed from any SQL,
because SQL ha
Hi
>> SQL access to variables needs a) change in SQL parser (with difficult
>> discussion about syntax) or b) generic get/set functions. @b can be used
>> in other PL in first iteration.
>>
>> I afraid to open pandora box and I would to hold the scope of this patch
>> too small what is possible
On 2/10/16 1:29 PM, Pavel Stehule wrote:
I got off list mail with little bit different syntax proposal
CREATE VARIABLE xxx DEFAULT [ PRIVATE ]
I am thinking so more SQL natural is form:
CREATE [ PRIVATE ] VARIABLE xxx ...
There should not be only variables, there can be tables, views,
functio
2016-02-10 20:25 GMT+01:00 Jim Nasby :
> On 2/10/16 1:17 PM, Pavel Stehule wrote:It is too simple and too like
> workaround :) I can do it this in plpgsql
>
>> extension probably.
>>
>
> I think it's something people will definitely want. If we don't have it,
> then they're going to be using schem
>>
>> The schema variables are private by design. It can be enhanced in
>> future, but now it is out my scope. If you need public access to these
>> variables, you can use a functions. The access to functions can be
>> controlled by a rights. We can introduce a private (schema limited)
>> function
On 2/10/16 1:17 PM, Pavel Stehule wrote:
2016-02-10 20:10 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>:
On 2/10/16 1:04 PM, Pavel Stehule wrote:
BTW, if all that's desired here are session variables for
plpgsql, I
think it makes a lot more sense
2016-02-10 20:10 GMT+01:00 Jim Nasby :
> On 2/10/16 1:04 PM, Pavel Stehule wrote:
>
>>
>> BTW, if all that's desired here are session variables for plpgsql, I
>> think it makes a lot more sense to start with implementing
>> per-function session variables. That's a lot simpler design-wi
On 2/10/16 1:04 PM, Pavel Stehule wrote:
BTW, if all that's desired here are session variables for plpgsql, I
think it makes a lot more sense to start with implementing
per-function session variables. That's a lot simpler design-wise and
is something we should have anyway. You do
On 2/10/16 11:33 AM, Pavel Stehule wrote:
I don't think that really makes sense. I would expect schema
variables to be exposed to a function as variables or attributes,
either in the global namespace for that PL, or as an attribute of
some object (ie the plpy object in plpython).
>> I didn't propose SESSION variables - now there are some workarounds how
>> to anybody can emulate it, so this feature can wait. What we need is
>> safe session variables with limited access. And the border can be
>> defined by schema scope. So the keyword SCHEMA has sense, and it is
>> necessary
On 2/10/16 11:25 AM, Pavel Stehule wrote:
Oh, and I suggest we call them SESSION variables rather than SCHEMA
variables, to reinforce the idea of how long the values in the
variables live. A session variable is in a sense a 1x1 temp table,
whose definition persists across session
On 2/10/16 11:54 AM, Pavel Stehule wrote:
2016-02-09 23:41 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>:
The other big thing you get is public vs private. You can
sorta-kinda-almost simulate that with permissions in simple cases,
but it ultimately falls apart as soon as you w
Hi
2016-02-09 23:41 GMT+01:00 Jim Nasby :
> On 2/9/16 4:13 PM, Corey Huinker wrote:
>
>>
>> We're not going to get source compatibility without implementing
>> packages, and there's no enthusiasm for that. It's been stated a few
>> times before by some that the only value they see in packages is
2016-02-09 23:31 GMT+01:00 Jim Nasby :
> On 2/8/16 10:02 AM, Pavel Stehule wrote:
>
>>
>> I think it would make sense to implement the interface in at least
>> one of our other supported PLs. I'm not entirely clear how well this
>> will match up with, say, plperl, but I'd be interested
2016-02-09 20:55 GMT+01:00 David G. Johnston :
> On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker
> wrote:
>
>>
>> Oh, and I suggest we call them SESSION variables rather than SCHEMA
>> variables, to reinforce the idea of how long the values in the variables
>> live. A session variable is in a sens
Hi
Would it make sense to explicitly import variables in function definitions?
>
> CREATE SESSION VARIABLE foo integer;
> CREATE SESSION VARIABLE my_schema.bar text;
> SET SESSION VARIABLE foo to 4;
> SET SESSION VARIABLE my_schema.bar to 'hi mom';
>
> CREATE FUNCTION my_func (p_param text) return
On 2/9/16 4:13 PM, Corey Huinker wrote:
We're not going to get source compatibility without implementing
packages, and there's no enthusiasm for that. It's been stated a few
times before by some that the only value they see in packages is the
package/session variables. Pavel's idea gives us that
On 2/8/16 10:02 AM, Pavel Stehule wrote:
I think it would make sense to implement the interface in at least
one of our other supported PLs. I'm not entirely clear how well this
will match up with, say, plperl, but I'd be interested to see.
The minimalistic interface can be based on
On Tue, Feb 9, 2016 at 2:55 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker
> wrote:
>
>>
>> Oh, and I suggest we call them SESSION variables rather than SCHEMA
>> variables, to reinforce the idea of how long the values in the variables
On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker
wrote:
>
> Oh, and I suggest we call them SESSION variables rather than SCHEMA
> variables, to reinforce the idea of how long the values in the variables
> live. A session variable is in a sense a 1x1 temp table, whose definition
> persists across se
On Tue, Feb 9, 2016 at 9:58 AM, Pavel Stehule
wrote:
>
>
> 2016-02-09 15:32 GMT+01:00 Marko Tiikkaja :
>
>> On 08/02/16 14:16, Pavel Stehule wrote:
>>
>>> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
>>>
Yeah, and that's exactly what I don't want, because that means that
CREATE
2016-02-09 15:32 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 14:16, Pavel Stehule wrote:
>
>> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
>>
>>>
>>> Yeah, and that's exactly what I don't want, because that means that
>>> CREATE
>>> SCHEMA VARIABLE suddenly breaks existing code.
>>>
>>>
>> theoretical
On 08/02/16 14:16, Pavel Stehule wrote:
2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
Yeah, and that's exactly what I don't want, because that means that CREATE
SCHEMA VARIABLE suddenly breaks existing code.
theoretically yes, but this conflict can be 100% detected - so no quiet bug
is possibl
Hi
>> I propose really basic functionality, that can be enhanced in future -
>> step by step. This proposal doesn't contain any controversial feature or
>> syntax, I hope. It is related to PLpgSQL only, but described feature can be
>> used from any PL languages with implemented interface.
>>
>
>
2016-02-08 16:45 GMT+01:00 jflack :
> On 02/08/2016 03:16 AM, Pavel Stehule wrote:
>
> > Only a owner of schema can edit functions inside schema
>
> Can't anyone granted CREATE on the schema do that? Would
> that be changed by this proposal?
>
yes, anybody with necessary rights can do it.
regard
[resending because thunderbird helpfully defaulted my sender
address to the one that -isn't- subscribed to -hackers, sorry]
On 02/08/2016 03:16 AM, Pavel Stehule wrote:
> Only a owner of schema can edit functions inside schema
Can't anyone granted CREATE on the schema do that? Would
that be cha
On 02/08/2016 03:16 AM, Pavel Stehule wrote:
Hi
On Russian PgConf I had a talk with Oleg about missing features in
PLpgSQL, that can complicates a migrations from Oracle to PostgreSQL.
Currently I see only one blocker - missing protected session
variables. PL/SQL has package variables with
2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 13:41, Pavel Stehule wrote:
>
>> 2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
>>
>>> Personally I find that undesirable. I don't know what oracle does, but
>>> variables being visible without schema-qualifying them can introduce
>>> variabl
On 08/02/16 13:41, Pavel Stehule wrote:
2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
Personally I find that undesirable. I don't know what oracle does, but
variables being visible without schema-qualifying them can introduce
variable conflicts in PL/PgSQL. I'd prefer if you could only refer to
2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 13:17, Pavel Stehule wrote:
>
>> 2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
>>
>>> How does this function know which schema variables are visible?
>>>
>>
>> function see all schema variables from same schema as function's schema
>>
>
> Per
On 08/02/16 13:17, Pavel Stehule wrote:
2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
How does this function know which schema variables are visible?
function see all schema variables from same schema as function's schema
Personally I find that undesirable. I don't know what oracle does, but
2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 09:16, Pavel Stehule wrote:
>
>> Usage
>> =
>>
>> DROP SCHEMA IF EXISTS test_schema CASCADE;
>> SET SCHEMA test_schema;
>>
>> CREATE SCHEMA VARIABLE local_counter AS int DEFAULT 0;
>>
>> CREATE OR REPLACE FUNCTION increment_counter()
>>
On 08/02/16 09:16, Pavel Stehule wrote:
Usage
=
DROP SCHEMA IF EXISTS test_schema CASCADE;
SET SCHEMA test_schema;
CREATE SCHEMA VARIABLE local_counter AS int DEFAULT 0;
CREATE OR REPLACE FUNCTION increment_counter()
RETURNS void AS $$
BEGIN
local_counter := local_counter + 1;
END;
$$ L
Hi
On Russian PgConf I had a talk with Oleg about missing features in PLpgSQL,
that can complicates a migrations from Oracle to PostgreSQL. Currently I
see only one blocker - missing protected session variables. PL/SQL has
package variables with possible only package scope and session life cycle.
37 matches
Mail list logo
