On Fri, Mar 26, 2010 at 10:19 PM, Joseph Adams
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 to store those variab
On Fri, Mar 26, 2010 at 12:07 PM, Robert Haas 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 inside the server. If
On Thu, Mar 25, 2010 at 11:42 PM, Joseph Adams
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
> script) due to connection po
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 = pg_quer
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 writes:
> Perhaps we could have some sort of LET statement that allows the
> client to pass data to the se
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
Robert Haas writes:
> On Tue, Mar 23, 2010 at 8:30 PM, Tom Lane 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 constraints depended on triggers. UNIQUE c
On Tue, Mar 23, 2010 at 8:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 23, 2010 at 8:16 PM, Tom Lane 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 pr
Robert Haas writes:
> On Tue, Mar 23, 2010 at 8:16 PM, Tom Lane 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 local users and global users
>> f
On Tue, Mar 23, 2010 at 8:16 PM, Tom Lane wrote:
> Alvaro Herrera 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
>>
Alvaro Herrera 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 roadblock.
I think it'd be a
Tom Lane escribió:
> Alvaro Herrera 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 of that is
>
Alvaro Herrera writes:
> Robert Haas escribió:
>> On Tue, Mar 23, 2010 at 1:28 PM, Josh Berkus 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 on
Robert Haas escribió:
> On Tue, Mar 23, 2010 at 1:28 PM, Josh Berkus 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.
>
> But
On Tue, Mar 23, 2010 at 1:28 PM, Josh Berkus 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 but not off, so
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
Peter Eisentraut 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 to allow "spec
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 simila
Robert Haas wrote:
> Does the SQL standard specify anything in this area?
The only thing that comes to mind for me is the SQL/PSM
.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
2010/3/22 Robert Haas :
> On Mon, Mar 22, 2010 at 9:39 AM, Stephen Frost 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 definitio
On Mon, Mar 22, 2010 at 10:03 AM, Stephen Frost 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 rear end:
>
* 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 woul
On Mon, Mar 22, 2010 at 9:39 AM, Stephen Frost 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 exposing a free v
* 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 f
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
>
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 to
26 matches
Mail list logo
