At Ottawa, I had a talk with Robert Haas about this reworks.
Because a part of ALTER TABLE options need information which can
be gathered at execution stage, not preparation stage, the patch
tried to move all the access control stuff into execution stage.
However, he pointed out it has a matter t
(2010/05/21 1:14), Robert Haas wrote:
> In yesterday's development meeting, we talked about the possibility of
> a basic SE-PostgreSQL implementation that checks permissions only for
> DML. Greg Smith offered the opinion that this could provide much of
> the benefit of SE-PostgreSQL for many users
On Wed, May 19, 2010 at 2:47 PM, Fujii Masao wrote:
>>> Oh, right. How about allowing the postmaster only in PM_STARTUP,
>>> PM_RECOVERY, PM_HOT_STANDBY or PM_WAIT_READONLY state to invoke
>>> walreceiver? We can keep walreceiver alive until all read only
>>> backends have gone, and prevent unexpe
Jan Wieck wrote:
ISTM we are in danger of confusing several different things. A user
that doesn't want data to be shared should not stash it in global
objects. But to me, trusting a language is not about making data
private, but about not allowing the user to do things that are
dangerous,
On 22/05/10 02:12, Robert Haas wrote:
On Fri, May 21, 2010 at 1:58 PM, David Fetter wrote:
On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
* David Fetter (da...@fetter.org) wrote:
That is *precisely* the business we need to be in, at least for the
languages we ship, and it woul
On 5/23/2010 10:04 PM, Andrew Dunstan wrote:
Jan Wieck wrote:
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas writes:
So... can we get back to coming up with a reasonable
definition,
(1) no access to system calls (including file and network I/O)
If a PL has file acces
On 21/05/10 23:55, Josh Berkus wrote:
So, here's a working definition:
1) cannot directly read or write files on the server.
It must also prevent PL-user-level access to file descriptors already
open by the backend. That's implicitly covered in the above, but should
probably be explicit.
Jan Wieck wrote:
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas writes:
So... can we get back to coming up with a reasonable
definition,
(1) no access to system calls (including file and network I/O)
If a PL has file access to it's own sandbox (similar to what
flash
On 5/23/2010 8:38 PM, Robert Haas wrote:
On Sun, May 23, 2010 at 4:21 PM, Jan Wieck wrote:
The system will have postgresql.conf options for enabling/disabling the
whole shebang, how many shared buffers to allocate for managing access
to the data and to define the retention period of the data ba
On 5/23/2010 4:48 PM, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Exposing the data will be done via a set returning function. The SRF
takes two arguments. The maximum number of rows to return and the last
serial number processed by the reader. The advantage o
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas writes:
So... can we get back to coming up with a reasonable
definition,
(1) no access to system calls (including file and network I/O)
If a PL has file access to it's own sandbox (similar to what
flash seems to do in web b
On Sun, May 23, 2010 at 4:21 PM, Jan Wieck wrote:
> The system will have postgresql.conf options for enabling/disabling the
> whole shebang, how many shared buffers to allocate for managing access
> to the data and to define the retention period of the data based on data
> volume and/or age of the
Tom Lane wrote:
> Robert Haas writes:
>> So... can we get back to coming up with a reasonable
>> definition,
>
> (1) no access to system calls (including file and network I/O)
If a PL has file access to it's own sandbox (similar to what
flash seems to do in web browsers), could that be considere
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Exposing the data will be done via a set returning function. The SRF
> takes two arguments. The maximum number of rows to return and the last
> serial number processed by the reader. The advantage of such SRF is that
> the result can be used i
In some systems (data warehousing, replication), the order of commits is
important, since that is the order in which changes have become visible.
This information could theoretically be extracted from the WAL, but
scanning the entire WAL just to extract this tidbit of information would
be excrucia
Robert Haas writes:
> Not every object type has a file, and the existing functions are split
> across three different directories, sometimes in files that don't
> really pertain to the object type being dealt with. I think this is
> going to be difficult to maintain if we intentionally spread out
On Sun, May 23, 2010 at 1:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 23, 2010 at 11:30 AM, Tom Lane wrote:
>>> I think both Stephen and I are saying we don't see merit in that.
>>> Moving around pre-existing functions won't accomplish much except
>>> causing include-list churn.
Robert Haas writes:
> On Sun, May 23, 2010 at 11:30 AM, Tom Lane wrote:
>> I think both Stephen and I are saying we don't see merit in that.
>> Moving around pre-existing functions won't accomplish much except
>> causing include-list churn. Let's just standardize the names/APIs
>> and be done.
On Sun, May 23, 2010 at 11:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 23, 2010 at 11:10 AM, Tom Lane wrote:
>>> I'm with Stephen on this one. I agree that standardizing the function
>>> names and behavior would be a good idea, but don't try to put them all
>>> in one place.
>
>
Pavel Stehule writes:
> --- a/contrib/pg_upgrade/check.c
> +++ b/contrib/pg_upgrade/check.c
> @@ -154,7 +154,6 @@ issue_warnings(migratorContext *ctx, char
> *sequence_script_file_name)
> ctx->new.bindir,
> ctx->new.port, sequence_script_file_name,
>
Pavel Stehule writes:
> postgres=# explain SELECT name
> FROM person
> WHERE name IN (
>SELECT name FROM person p
>LEFT JOIN person_data ON p.id = person_data.id);
> ERROR: failed to build any 2-way joins
Fixed, thanks.
regards, tom lane
--
Sent via pgs
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Ugh. Moving that to c.h doesn't render it not junk code. (For one
> thing, it will not operate as intended if you haven't previously
> #included , which in fact is not included in c.h.)
Doh.
> If we need this we should do it properly with autoconf.
My a
Robert Haas writes:
> On Sun, May 23, 2010 at 11:10 AM, Tom Lane wrote:
>> I'm with Stephen on this one. I agree that standardizing the function
>> names and behavior would be a good idea, but don't try to put them all
>> in one place.
> Some of the existing functions are in lsyscache.c, some a
Stephen Frost writes:
> While reviewing bfba40e2c7b3909d3de13bd1b83b7e85fa8dfec2 (mmm, we like
> git diff -p), I noted that c.h is already included by both extern.h
> and ecpg.header through postgres_fe.h. Given this and that we're
> already doing alot of similar #define's there (unlike i
On Sun, May 23, 2010 at 11:10 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> Long story short, this is kind of a mess.
>
>> ... I think it would be good to have a
>> consistant naming/calling scheme for these various functions, but I'm
>> not sure
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Long story short, this is kind of a mess.
> ... I think it would be good to have a
> consistant naming/calling scheme for these various functions, but I'm
> not sure that moving them all to the same place makes sense.
I'm wi
* Robert Haas (robertmh...@gmail.com) wrote:
> Long story short, this is kind of a mess.
I agree that it's a bit of a mess.
> What I would propose is that we create a new source
> file somewhere (maybe utils/cache), move all of the other functions of
> this type there, give them standardized name
27 matches
Mail list logo
