On Fri, Mar 26, 2010 at 10:19 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
One problem with a textual substitution is that implicit variable use
(e.g. selecting from a view) can't be substituted, at least not
trivially. As for sending unnecessary variables with every query,
my idea was
Disclaimer: the following is only my view on the matter and is not meant
as representative of the project views, which are reached through
discussion and consensus. IOW, my 2¢.
Joseph Adams joeyadams3.14...@gmail.com writes:
Perhaps we could have some sort of LET statement that allows the
On 3/26/10 5:42 AM +0200, Joseph Adams wrote:
// New libpq function
pg_set('current_user', 'bob');
$result = pg_query_params(
'SELECT answer FROM secrets WHERE user=current_user AND question=$1',
array('Birth place'));
What this really does is something like:
$result =
On Thu, Mar 25, 2010 at 11:42 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
From what I can tell, a big problem with my jails idea (as well as the
variables Robert described) is that there really isn't a way to store
context in the backend specifically for the end client (e.g. a PHP
On Fri, Mar 26, 2010 at 12:07 PM, Robert Haas robertmh...@gmail.com wrote:
Hmm. I'm not sure exactly what problem you're trying to solve here.
I don't think this is a particularly good design for supporting
variables inside the server, since, well, it doesn't actually support
variables
I apologize for my silence, as I've been busy reading up more on the
internals of PostgreSQL.
From what I can tell, a big problem with my jails idea (as well as the
variables Robert described) is that there really isn't a way to store
context in the backend specifically for the end client (e.g. a
Peter Eisentraut pete...@gmx.net writes:
Well, sudo is pretty useful, and this would be quite similar.
+1.
I guess one of the big difficulties would be to be able to match a given
random query with the list of queries we have in any Jail, given that we
put in there generic queries and we want
On 3/21/10 9:36 PM, Joseph Adams wrote:
Inside of the jail definition is a series of pseudo-statements that
indicate the space of queries the user can perform. Simply creating a
jail does not make it go into effect. A jail is activated using
another query, and it remains in effect for the
On Tue, Mar 23, 2010 at 1:28 PM, Josh Berkus j...@agliodbs.com wrote:
I don't think that the idea of turning on the jail mode via a
session-level switch works, given the realities of connection pooling.
Also, I do not believe that we currently have any USERSET variable which
can be turned on
Robert Haas escribió:
On Tue, Mar 23, 2010 at 1:28 PM, Josh Berkus j...@agliodbs.com wrote:
BTW, if you wanted something less ambitious, we have a longstanding
request to implement local superuser, that is, the ability to give one
role the ability to edit other roles in one database only.
Alvaro Herrera alvhe...@commandprompt.com writes:
Robert Haas escribió:
On Tue, Mar 23, 2010 at 1:28 PM, Josh Berkus j...@agliodbs.com wrote:
BTW, if you wanted something less ambitious, we have a longstanding
request to implement local superuser, that is, the ability to give one
role the
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Robert Haas escribi�:
But roles aren't database-specific... they're globals.
Well, that's another longstanding request ;-) (See the
db_user_namespace hack)
Yeah, you'd have to fix that first. The ambitious part
Alvaro Herrera alvhe...@commandprompt.com writes:
I wonder if this is simpler now that we got rid of the flat files stuff.
We could validate the user once we've connected to a database and thus
able to poke at the local user catalog, not just the global one. I
think that was a serious
On Tue, Mar 23, 2010 at 8:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I wonder if this is simpler now that we got rid of the flat files stuff.
We could validate the user once we've connected to a database and thus
able to poke at the local user
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 23, 2010 at 8:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My first thought about a catalog representation would be to add a column
to pg_auth which is a DB OID for local users or zero for global users.
However, you'd probably want to prevent
On Tue, Mar 23, 2010 at 8:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 23, 2010 at 8:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My first thought about a catalog representation would be to add a column
to pg_auth which is a DB OID for local
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 23, 2010 at 8:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not unless you'd like to solve the issues with triggers on system
catalogs first ...
Urp. Not really, though I don't know what they are exactly. I didn't
think exclusion
Joseph Adams wrote:
Hello, I'm Joey Adams, and I'm interested in applying for Google
Summer of Code to work on PostgreSQL. I'm a former GSoC student (I
worked on CCAN last year), and a strong C programmer, though I am
still new to working with large, established communities. I apologize
if
* Joseph Adams (joeyadams3.14...@gmail.com) wrote:
I propose adding application-level access control to PostgreSQL via a
jails concept. In a nutshell, a jail is created as part of the
database definition (typically exposing a free variable for the
current user). When a jail is activated for
On Mon, Mar 22, 2010 at 9:39 AM, Stephen Frost sfr...@snowman.net wrote:
* Joseph Adams (joeyadams3.14...@gmail.com) wrote:
I propose adding application-level access control to PostgreSQL via a
jails concept. In a nutshell, a jail is created as part of the
database definition (typically
* Robert Haas (robertmh...@gmail.com) wrote:
Sometimes it would be nice to conditionalize queries on a value other
than the authenticated role. I really wish we had some kind of SQL
variable support. Talking out of my rear end:
I certainly agree- having variable support in the backend would
On Mon, Mar 22, 2010 at 10:03 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Sometimes it would be nice to conditionalize queries on a value other
than the authenticated role. I really wish we had some kind of SQL
variable support. Talking out of my
2010/3/22 Robert Haas robertmh...@gmail.com:
On Mon, Mar 22, 2010 at 9:39 AM, Stephen Frost sfr...@snowman.net wrote:
* Joseph Adams (joeyadams3.14...@gmail.com) wrote:
I propose adding application-level access control to PostgreSQL via a
jails concept. In a nutshell, a jail is created as
Robert Haas robertmh...@gmail.com wrote:
Does the SQL standard specify anything in this area?
The only thing that comes to mind for me is the SQL/PSM
SQL variable declaration.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On mån, 2010-03-22 at 09:54 -0400, Robert Haas wrote:
We have had one previous request for the ability to limit the list of
queries that the user can issue to a fixed set, but it's not clear to
me that that's really all that useful.
Well, sudo is pretty useful, and this would be quite similar.
Hello, I'm Joey Adams, and I'm interested in applying for Google
Summer of Code to work on PostgreSQL. I'm a former GSoC student (I
worked on CCAN last year), and a strong C programmer, though I am
still new to working with large, established communities. I apologize
if this is the wrong place
26 matches
Mail list logo
