proposal: custom variables management

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

* reset_custom_variable(cusvar); ... set default from postgresql.conf
* revoke_custom_variable(READ|MODIFY, cusvar, roleid);
* grant_custom_variable(READ|MODIFY, cusvar, roleid);

This seems pointlessly complex. An unprivileged user can only SET the
value within his own session, and if there are any reasons he shouldn't
be able to set it, the existing GUC protection categories seem
sufficient. What's the use-case for all this new mechanism?

Related discussion:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php

Considering no one's bothered to implement that yet, I don't see that
there's a groundswell of demand for something more complicated.

regards, tom lane

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

* reset_custom_variable(cusvar); ... set default from postgresql.conf
* revoke_custom_variable(READ|MODIFY, cusvar, roleid);
* grant_custom_variable(READ|MODIFY, cusvar, roleid);

This seems pointlessly complex. An unprivileged user can only SET the
value within his own session, and if there are any reasons he shouldn't
be able to set it, the existing GUC protection categories seem
sufficient. What's the use-case for all this new mechanism?

I would to use custom variables like session variables and I thing so can be
usefull for security definer procedures. But I count with sharing current
code. With described functions I don't need distribute superusers access. I
am not sure, how much code I have to write. Maybe too much. Then I'll prefer
minimalistic version later:

reset_custom_variable(cusvar);
armor custom_variable(cusvar);

I would to test more general solution first

Related discussion:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php

Considering no one's bothered to implement that yet, I don't see that
there's a groundswell of demand for something more complicated.

regards, tom lane

_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/

Pavel Stehule wrote:

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

* reset_custom_variable(cusvar); ... set default from postgresql.conf
* revoke_custom_variable(READ|MODIFY, cusvar, roleid);
* grant_custom_variable(READ|MODIFY, cusvar, roleid);

This seems pointlessly complex. An unprivileged user can only SET the
value within his own session, and if there are any reasons he shouldn't
be able to set it, the existing GUC protection categories seem
sufficient. What's the use-case for all this new mechanism?

I would to use custom variables like session variables and I thing so
can be usefull for security definer procedures. But I count with
sharing current code. With described functions I don't need distribute
superusers access. I am not sure, how much code I have to write. Maybe
too much. Then I'll prefer minimalistic version later:

reset_custom_variable(cusvar);
armor custom_variable(cusvar);

I would to test more general solution first

Related discussion:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php

Considering no one's bothered to implement that yet, I don't see that
there's a groundswell of demand for something more complicated.

Pavel,

ISTM you are trying to do too much. We need to get the base
functionality, as described by Tom in the thread I referred you to,
working first. Extra stuff could be added later if necessary.

cheers

andrew

ISTM you are trying to do too much. We need to get the base functionality,
as described by Tom in the thread I referred you to, working first. Extra
stuff could be added later if necessary.

cheers

I don't wont to build cathedral. Now is time for discussion, no? I am
collect any arguments. With "enhanced" custom variables we can fill modules
hole in plpgsql or any pl. With it security definer's procedures in any
languages can safety share values. I worked on large wramework designed for
plpgsql, and we had to store some temp values in temporary tables. Safe
custom variables can be solution. It's only idea, nothing more.

Regards
Pavel Stehule

_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/

Pavel Stehule wrote:

ISTM you are trying to do too much. We need to get the base
functionality, as described by Tom in the thread I referred you to,
working first. Extra stuff could be added later if necessary.

cheers

I don't wont to build cathedral. Now is time for discussion, no? I am
collect any arguments. With "enhanced" custom variables we can fill
modules hole in plpgsql or any pl. With it security definer's
procedures in any languages can safety share values. I worked on large
wramework designed for plpgsql, and we had to store some temp values
in temporary tables. Safe custom variables can be solution. It's only
idea, nothing more.

Right now the main uses I have seen referred to only involve doing
custom variables right, rather than exposing any extra API. For example,
in plperl we might have a variable that contains a list of modules
considered safe to load, and preload them. We would obviously want that
to be PGC_SUSET, at least. But this only needs DefineCustomFooVariable()
to work right. Nothing would need to be exposed to plperl itself, and no
extra functionality is needed for at the C level. If you think there's a
case for some extra functionality to be exposed, maybe you could provide
some more examples / use cases.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

If you think there's a
case for some extra functionality to be exposed, maybe you could provide
some more examples / use cases.

I think what Pavel is on about is making use of not-known-to-C-code
custom variables as all-purpose intrasession storage. However, I doubt
that insufficient granularity of protection is the first problem
standing in the way of that --- the GUC mechanism was never designed to
scale up to huge numbers of variables, and will likely start to perform
poorly if anyone tries to make extensive use of such variables. But
perhaps more to the point, I'm unconvinced that we should encourage
what's basically an abuse of the GUC mechanism. It's a handy hack at
the moment, but what if we want to change GUC later in a way that
prevents being backward compatible with this behavior? It's not
impossible for example that we might want to load the defining module
immediately when someone tries to set a custom variable, rather than
letting the value skate by unchecked. Also, while GUC is underdesigned
for the purpose of intrasession storage in some ways, it is overdesigned
in others --- the whole postgresql.conf, SIGHUP, etc mechanism is
irrelevant. So it's really a pretty poor fit. If we want to support
general-purpose intrasession variables, I think something other than GUC
ought to be providing 'em. (And, of course, it seems likely that you
could provide such functionality with a few functions in
your-favorite-PL, without any core changes at all.)

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

If you think there's a
case for some extra functionality to be exposed, maybe you could provide
some more examples / use cases.

I think what Pavel is on about is making use of not-known-to-C-code
custom variables as all-purpose intrasession storage. However, I doubt
that insufficient granularity of protection is the first problem
standing in the way of that --- the GUC mechanism was never designed to
scale up to huge numbers of variables, and will likely start to perform
poorly if anyone tries to make extensive use of such variables. But
perhaps more to the point, I'm unconvinced that we should encourage
what's basically an abuse of the GUC mechanism. It's a handy hack at
the moment, but what if we want to change GUC later in a way that
prevents being backward compatible with this behavior? It's not
impossible for example that we might want to load the defining module
immediately when someone tries to set a custom variable, rather than
letting the value skate by unchecked. Also, while GUC is underdesigned
for the purpose of intrasession storage in some ways, it is overdesigned
in others --- the whole postgresql.conf, SIGHUP, etc mechanism is
irrelevant. So it's really a pretty poor fit. If we want to support
general-purpose intrasession variables, I think something other than GUC
ought to be providing 'em. (And, of course, it seems likely that you
could provide such functionality with a few functions in
your-favorite-PL, without any core changes at all.)

I think I agree with you :-)

But then every PL needs to invent it's own variable persistence - maybe
we should look at providing a general PL-visible persistence mechanism
which is distinct from GUC, so we don't have to keep reinventing the
wheel (YAML anyone?).

I think the use I had in mind for properly working custom variables fits
more squarely with common GUC usage, though.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

... So it's really a pretty poor fit. If we want to support
general-purpose intrasession variables, I think something other than GUC
ought to be providing 'em. (And, of course, it seems likely that you
could provide such functionality with a few functions in
your-favorite-PL, without any core changes at all.)

I think I agree with you :-)

But then every PL needs to invent it's own variable persistence

Why? You do it once, you can call it from SQL or any PL. Doing it in a
PL would constrain you to using a function-like syntax whereas a core
feature would have more flexibility of syntax, but I don't see that as a
big advantage --- looking at GUC's history, we've added function-style
APIs (current_setting() etc) when we already had specialized syntax.

regards, tom lane

I think I agree with you :-)

But then every PL needs to invent it's own variable persistence - maybe we
should look at providing a general PL-visible persistence mechanism which
is distinct from GUC, so we don't have to keep reinventing the wheel (YAML
anyone?).

I know, so GUC aren't optimal for it. Any storage of Datum values can be
better. I am thinking about using one row memory tables (similar ROW type
from plpgsql). And access via clasic SQL statements. It's need only some
game with executor and type cache. It can be cheaper than temporary tables
with same functionality.

Using:
* trusted storage for debug info
* trusted storage for state variables (vector)
* trusted storage for expensive variables
* trusted sharing values between PL

I think the use I had in mind for properly working custom variables fits
more squarely with common GUC usage, though.

I'll try implement my minimalistic version.

Regards
Pavel Stehule

_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/

On Mon, Mar 05, 2007 at 06:54:36PM -0500, Andrew Dunstan wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

If you think there's a case for some extra functionality to be
exposed, maybe you could provide some more examples / use cases.

I think what Pavel is on about is making use of not-known-to-C-code
custom variables as all-purpose intrasession storage. However, I
doubt that insufficient granularity of protection is the first
problem standing in the way of that --- the GUC mechanism was never
designed to scale up to huge numbers of variables, and will likely
start to perform poorly if anyone tries to make extensive use of
such variables. But perhaps more to the point, I'm unconvinced
that we should encourage what's basically an abuse of the GUC
mechanism. It's a handy hack at the moment, but what if we want to
change GUC later in a way that prevents being backward compatible
with this behavior? It's not impossible for example that we might
want to load the defining module immediately when someone tries to
set a custom variable, rather than letting the value skate by
unchecked. Also, while GUC is underdesigned for the purpose of
intrasession storage in some ways, it is overdesigned in others ---
the whole postgresql.conf, SIGHUP, etc mechanism is irrelevant. So
it's really a pretty poor fit. If we want to support
general-purpose intrasession variables, I think something other
than GUC ought to be providing 'em. (And, of course, it seems
likely that you could provide such functionality with a few
functions in your-favorite-PL, without any core changes at all.)

I think I agree with you :-)

But then every PL needs to invent it's own variable persistence -
maybe we should look at providing a general PL-visible persistence
mechanism which is distinct from GUC, so we don't have to keep
reinventing the wheel (YAML anyone?).

YAML could work, but JSON <http://www.json.org/&gt; is a lot less
sensitive to what should be trivial matters of whitespace.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate