I understand Simon is extremely busy on his own patch. I appreciate
if anyone help the review.
2009/2/6 Fujii Masao :
> Hi,
>
> On Tue, Feb 3, 2009 at 5:08 AM, Bruce Momjian wrote:
>>> o Others
>>
>> We will focus on all the other items on the commit fest page, and that
>> will determine
Hi,
On Tue, Feb 3, 2009 at 5:08 AM, Bruce Momjian wrote:
>> o Others
>
> We will focus on all the other items on the commit fest page, and that
> will determine our time-line for 8.4 beta, i.e. the first three items
> will not delay our beta release.
Simon is assigned as reviewer of PITR
To summarize where I think we are, release-wise:
> o Log streaming
hold for 8.5
> o Hot standby
if committable for 8.4, fine, if not, 8.5, Heikki decides
> o SE-PostgreSQL
no row-level security, if committable for 8.4, fine, if not, 8.5
> o Others
We will focus o
Peter Eisentraut wrote:
On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote:
well from a quick glance there is the bugzilla demo install as well as
pieces of reviewboard and patchwork on the trackerdemo jail.
So what's the URL and where can we sign up?
resurrected the install and
On Thursday 29 January 2009 12:03:45 Robert Haas wrote:
> I
> don't believe that you can speed a project up much by adjusting the
> length of the release cycle, but it is *sometimes* possible to speed
> up a project by dividing up the work over more people.
>
This is interesting. We had a problem
Stefan Kaltenbrunner píše v čt 29. 01. 2009 v 18:29 +0100:
> Peter Eisentraut wrote:
> > On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote:
> >> well from a quick glance there is the bugzilla demo install as well as
> >> pieces of reviewboard and patchwork on the trackerdemo jail.
>
Josh Berkus writes:
> But that's *not* actually how we do things. So you're making my point.
Well, the stuff around the wiki status board is pretty new and I don't
think anyone feels that it's set in stone yet. The thing we don't want
to compromise on, IMHO, is that the long-term record of what
Josh,
Someone submits patch
ticket is created
reviewer takes ticket
comments
submitter takes ticket
fixes based on comments
review takes ticket
approves
if reviewer is a committers, he commits.
if reviewer isn't he set the ticket to "need final review"
tickets that are in that state are rev
On Thu, 2009-01-29 at 10:18 -0800, Josh Berkus wrote:
> All,
>
> Thing is, our review/commit process is so peculiar to our project that
> using *any* prebuilt solution would require us to change our process to
> support the tool. And I can't imagine this group doing that.
I am not sure I agree
All,
Thing is, our review/commit process is so peculiar to our project that
using *any* prebuilt solution would require us to change our process to
support the tool. And I can't imagine this group doing that.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Peter Eisentraut wrote:
On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote:
well from a quick glance there is the bugzilla demo install as well as
pieces of reviewboard and patchwork on the trackerdemo jail.
So what's the URL and where can we sign up?
note the "pieces" part of m
> I wish we could get rid of the whole concept and stigma of being "bumped" your
> patch will be released in the next release after it's committed. What does it
> matter if there's been another release since you started or not?
It matters because the intervening beta/release cycle is likely to sap
On Thursday 29 January 2009 08:39:48 Gregory Stark wrote:
> I wish we could get rid of the whole concept and stigma of being "bumped"
> your patch will be released in the next release after it's committed. What
> does it matter if there's been another release since you started or not?
>
This is th
On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote:
> well from a quick glance there is the bugzilla demo install as well as
> pieces of reviewboard and patchwork on the trackerdemo jail.
So what's the URL and where can we sign up?
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Robert Haas writes:
>> read up-thread, i've already shown that this would not be the case. remember,
>> we reduce the pressure from the large, complex patches that bottleneck the
>> process, which allows more parralell review/commit.
>
> I read what you wrote - I just don't believe it. My own ex
> read up-thread, i've already shown that this would not be the case. remember,
> we reduce the pressure from the large, complex patches that bottleneck the
> process, which allows more parralell review/commit.
I read what you wrote - I just don't believe it. My own experience is
that doing more
Magnus Hagander wrote:
Stefan Kaltenbrunner wrote:
Magnus Hagander wrote:
On 29 jan 2009, at 05.35, Bruce Momjian wrote:
Peter Eisentraut wrote:
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut wrote:
On Tuesday 27 January 2009
Stefan Kaltenbrunner wrote:
> Magnus Hagander wrote:
>>
>>
>> On 29 jan 2009, at 05.35, Bruce Momjian wrote:
>>
>>> Peter Eisentraut wrote:
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
> Marko Kreen wrote:
>> On 1/27/09, Peter Eisentraut wrote:
>>> On Tuesday 27 Jan
Magnus Hagander wrote:
On 29 jan 2009, at 05.35, Bruce Momjian wrote:
Peter Eisentraut wrote:
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
Such app already exists
On Wednesday 28 January 2009 23:42:11 Robert Haas wrote:
> > Our usual process *is* to try and circumvent our usual process. And I
> > believe it will continue to be that way until we lower the incentive to
> > lobby for circumvention.
>
> I think Tom and Bruce have both pretty much stated that the
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > OK, time for me to chime in.
> >
> > I think the outstanding commit-fest items can be broken down into four
> > sections:
> >
> > o Log streaming
> > o Hot standby
> > o SE-PostgreSQL
> > o Others
>
> - snip -
>
> > SE-Postgre
> Our usual process *is* to try and circumvent our usual process. And I believe
> it will continue to be that way until we lower the incentive to lobby for
> circumvention.
I think Tom and Bruce have both pretty much stated that they're not
keen on a shorter release cycle, and they're the ones who
Robert Treat wrote:
On Wednesday 28 January 2009 20:12:40 Bruce Momjian wrote:
Robert Treat wrote:
The revisionism was that of "remarkable failure". That was our shortest
release cycle in the modern era. And it didn't have the advantage of the
commitfest process.
But I think what is
On Wednesday 28 January 2009 20:12:40 Bruce Momjian wrote:
> Robert Treat wrote:
> > The revisionism was that of "remarkable failure". That was our shortest
> > release cycle in the modern era. And it didn't have the advantage of the
> > commitfest process.
> >
> > But I think what is important he
Gregory Stark wrote:
> I'm a bit shocked by how long Tom expects the release cycle to take even if we
> froze the code today. I guess I forget how long it takes and how many steps
> there are from past releases. If it's going to be 9+ months between Nov 1st
> and the first commitfest I'm worried ab
Robert Treat wrote:
> > We are going to have exactly
> > no credibility if we tell Simon et al "we're pushing these patches to
> > 8.5, but don't worry, it'll be a short release cycle".
> >
>
> The other options being we stall 8.4 indefinatly waiting for HS (which,
> honestly I am comfortable wi
Robert Treat wrote:
> The revisionism was that of "remarkable failure". That was our shortest
> release cycle in the modern era. And it didn't have the advantage of the
> commitfest process.
>
> But I think what is important here is to recognize why it didn't work. Once
> again we ended up wi
On Wed, 2009-01-28 at 17:04 -0500, Tom Lane wrote:
> The key committers are overstressed already.
Some developers are too.
I'm sure there's a way to avoid it being a zero-sum game.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-ha
Simon Riggs wrote:
>
> On Tue, 2009-01-27 at 15:46 -0500, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Not to pick on you personally, but this is the kind of review that should
> > > have
> > > happened six months ago, not during a "why is our development process
> > > inadequate" discus
Peter Eisentraut wrote:
> On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> > > As one of the earlier reviewers, I think the design is OK, but the way
> > > the implementation is presented was not acceptable, and very little has
> > > been ac
Bruce Momjian writes:
> Tom Lane wrote:
>> As the SEPostgres patch is constructed, the planner could *never* trust
>> an FK for optimization since it would have no way to know whether row
>> level permissions might be present (perhaps only for some rows) at
>> execution time. You could only get b
Robert Haas wrote:
> > The flaw in that argument is that as you are doing it, the
> > de-optimization only happens on queries that actually need the behavior.
> > As the SEPostgres patch is constructed, the planner could *never* trust
> > an FK for optimization since it would have no way to know wh
Simon Riggs wrote:
>
> On Tue, 2009-01-27 at 14:18 -0500, Tom Lane wrote:
> > Joshua Brindle writes:
> > > Tom Lane wrote:
> > >> Right, which is why it's bad for something like a foreign key constraint
> > >> to expose the fact that the row does exist after all.
> >
> > > Once again, this is no
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane wrote:
> >> Right, but you expect that to be a small and predictable cost, say in
> >> the single-digits-percentage range. Plan optimizations that
> >> suddenly stop happening can cost you multiple orders of mag
On Wednesday 28 January 2009 12:35:42 Tom Lane wrote:
> Robert Treat writes:
> > On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote:
> >> We're still going to have to pay the full cost of doing a release every
> >> time. With beta/rc management, release notes, announcements, postings,
> >
> I considered pg_upgrade one of the "others" on the list; it is not as
> complex as the previous three.
LOL.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Zdenek Kotala wrote:
>
> Bruce Momjian p??e v po 26. 01. 2009 v 23:02 -0500:
> > OK, time for me to chime in.
> >
> > I think the outstanding commit-fest items can be broken down into four
> > sections:
> >
> > o Log streaming
> > o Hot standby
> > o SE-PostgreSQL
> > o Other
Dimitri Fontaine writes:
> Le 28 janv. 09 à 16:22, Simon Riggs a écrit :
>> The only way to keep the dev window open longer is to overlap the
>> start of the next cycle with the previous one. i.e. branch new version
>> before final release.
> This is the second time the idea is raised and
Le 28 janv. 09 à 16:22, Simon Riggs a écrit :
The only way to keep the dev window open longer is to overlap the
start
of the next cycle with the previous one. i.e. branch new version
before
final release.
This is the second time the idea is raised and I like it.
Do we have anywhere near e
Robert Treat writes:
> On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote:
>> We're still going to have to pay the full cost of doing a release every
>> time. With beta/rc management, release notes, announcements, postings,
>> packaging and all those things.
> As I pointed out to Tom, by
On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote:
> We're still going to have to pay the full cost of doing a release every
> time. With beta/rc management, release notes, announcements, postings,
> packaging and all those things.
>
As I pointed out to Tom, by percentage the additional
On Wed, 2009-01-28 at 14:55 +0100, Magnus Hagander wrote:
> If the release is pushed back, maybe some other patch could also have
> been finished by the new deadline - should that also be included? What
> about a completely new feature that isn't even started yet, but that
> could easily be finis
On Wed, Jan 28, 2009 at 11:31:25AM +0900, KaiGai Kohei wrote:
> As I noted before, there is a symmetrical structure between
> OS and DBMS.
Well, you said that before. I think your analogy is awful. I don't
think the similarities are nearly as great as you think, and I also
think there are signi
Magnus Hagander writes:
> Josh Berkus wrote:
>>
>> One client is planning on deploying a rather complex FS cloning
>> infrastructure just to have a bunch of reporting, testing and read-only
>> search databases they need. They'd be thrilled with an HS feature which
>> produced DBs which were an
Robert Haas wrote:
>> I think the best thing we could do overall is to set release dates and
>> stick to them. If your patch is not ready, well, at least it will get
>> out in a defined amount of time. Right now, the *real* problem with it
>> being pushed to the next release is you don't know how
Josh Berkus wrote:
>
>> That's modest. I've talked to several oracle and db2 shops that want a
>> standby for reporting that has relatively easy setup/maintenance
>> (handling ddl is a big part of this) and the HS feature your working
>> on will give them something as good as what they are getting
Robert Treat wrote:
> The problem is that the pain point is extremely high for missing a given
> release cycle. If you don't make a specific release, you have a 12-14 month
> wait for feature arrival. Given that choice, someone who deperately need (aka
> wants) HS/SEPostgres/Win32/HOT/IPU/etc...
On Wed, Jan 28, 2009 at 4:28 AM, Peter Eisentraut wrote:
> Greg Smith wrote:
>
>> PostgreSQL advocacy point, one of the questions Tom asked about a bit
>> upthread is still a bit hazy here. There are commercial database offerings
>> selling into the "trusted" space already. While the use-cases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Magnus Hagander a écrit :
> Peter Eisentraut wrote:
>> On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
>>> Marko Kreen wrote:
On 1/27/09, Peter Eisentraut wrote:
> On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
> > Suc
Peter Eisentraut wrote:
> On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
>> Marko Kreen wrote:
>>> On 1/27/09, Peter Eisentraut wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
> Such app already exists:
>
> http://ozlabs.org/~jk/projects/patchwork
Richard Huxton wrote:
Greg Smith wrote:
Where I suspect this is all is going to settle down into is that if 1)
the SE GUC is on and 2) one of the tables in a join has rows filtered,
then you can expect that a) it's possible that the result will leak
information, which certainly need to be docume
Greg Smith wrote:
PostgreSQL advocacy point, one of the questions Tom asked about a bit
upthread is still a bit hazy here. There are commercial database
offerings selling into the "trusted" space already. While the use-cases
you describe make perfect sense, I don't think it's clear to everyon
Greg Smith wrote:
> Where I suspect this is all is going to settle down into is that if 1)
> the SE GUC is on and 2) one of the tables in a join has rows filtered,
> then you can expect that a) it's possible that the result will leak
> information, which certainly need to be documented,
As far as
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
> Marko Kreen wrote:
> > On 1/27/09, Peter Eisentraut wrote:
> >> On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
> >> > Such app already exists:
> >> >
> >> > http://ozlabs.org/~jk/projects/patchwork/
> >> >
> >> > So it's a
On Tuesday 27 January 2009 21:07:48 Tom Lane wrote:
> Robert Treat writes:
> > The more I think about it, the more I feel that where we failed for 8.3
> > was not having a short 8.4 cycle lined up, which would give more freedom
> > to bump patches to the next release.
>
> Heh. The reason we wante
Greg Smith wrote:
Where I suspect this is all is going to settle down into is that if 1)
the SE GUC is on and 2) one of the tables in a join has rows filtered,
then you can expect that a) it's possible that the result will leak
information, which certainly need to be documented, and b) the
opt
Jaime Casanova wrote:
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane wrote:
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what S
Tom Lane wrote:
> The flaw in that argument is that as you are doing it, the
> de-optimization only happens on queries that actually need the behavior.
> As the SEPostgres patch is constructed, the planner could *never* trust
> an FK for optimization since it would have no way to know whether row
>
On Wed, 28 Jan 2009, KaiGai Kohei wrote:
It shows a fact that not negligible number of users accept row-level
granularity, even if it has covert channels.
From my read of the examples that Chad provided, keeping the existence of
things secret from complete outsiders doesn't look like the prim
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane wrote:
>
> This seems to me to be exactly parallel to deciding that SELinux should
> control only table/column permissions within SQL; an approach that would
> be enormously less controversial, less expensive, and more reliable than
> what SEPostgres tries
> I think the best thing we could do overall is to set release dates and
> stick to them. If your patch is not ready, well, at least it will get
> out in a defined amount of time. Right now, the *real* problem with it
> being pushed to the next release is you don't know how successful some
> othe
Joshua Brindle wrote:
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace
part, this is where the core interfaces to the security backends, and
you'll see a rowacl backend and an sepgsql backend.
Right, guess
Ron Mayer writes:
> Tom Lane wrote:
>> I think the best thing we could do overall is to set release dates and
>> stick to them.
> On the other hand, we might be better throwing out release dates
> and releasing at the end of any Commit Fest where there is enough
> demand/interest.
> Then we co
Tom Lane wrote:
> Joshua Brindle writes:
>> Tom Lane wrote:
>>> Right, which is why it's bad for something like a foreign key constraint
>>> to expose the fact that the row does exist after all.
>
>> Once again, this is not an issue for us.
>
> Yes it is an issue; claiming it isn't doesn't make
Tom Lane wrote:
> Heh. The reason we wanted a short 8.3 cycle was so we could push out
> patches that had been held over from 8.2. We are going to have exactly
> no credibility if we tell Simon et al "we're pushing these patches to
> 8.5, but don't worry, it'll be a short release cycle".
>
> I t
Andrew Sullivan wrote:
On Tue, Jan 27, 2009 at 12:41:36PM -0500, Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like WHERE
pg_accessible(
On Tue, 2009-01-27 at 21:07 -0500, Tom Lane wrote:
> Robert Treat writes:
> > The more I think about it, the more I feel that where we failed for 8.3 was
> > not having a short 8.4 cycle lined up, which would give more freedom to
> > bump
> > patches to the next release.
>
> Heh. The reason
Robert Treat writes:
> The more I think about it, the more I feel that where we failed for 8.3 was
> not having a short 8.4 cycle lined up, which would give more freedom to bump
> patches to the next release.
Heh. The reason we wanted a short 8.3 cycle was so we could push out
patches that ha
On 1/27/09 6:57 PM, "Greg Smith" wrote:
> On Tue, 27 Jan 2009, Chad Sellers wrote:
>
>> I'll speak to this a bit (Josh is also a Tresys employee). I can't say who
>> my customers are, but I can speak to their needs. They really need row-level
>> mandatory access controls (so both).
>
> From the
Joshua Brindle wrote:
Tom Lane wrote:
Ron Mayer writes:
It seems to me that there are two different standards to which this
feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid craf
On Tuesday 27 January 2009 19:04:49 Tom Lane wrote:
> Robert Treat writes:
> > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
> >> We have tried the short release cycle before, it was called 8.2. It
> >> fails, remarkably.
> >
> > I think this is a bit of revisionsit history.
>
> JD go
Here is morning now, so I started to follow the discussion now...
Stephen Frost wrote:
> * Gregory Stark (st...@enterprisedb.com) wrote:
>> It does seem weird to simply omit records rather than throw an error and
>> require the user to use a where clause, even if it's something like WHERE
>> pg_ac
On Tuesday 27 January 2009 18:51:01 Tom Lane wrote:
> Robert Treat writes:
> > Now I am starting to think that we cannot prevent large patches from
> > showing up at the end of a cycle no matter what, and the only way to
> > really "solve" that problem is to lesson the pain of getting bumped from
Robert Treat writes:
> On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
>> We have tried the short release cycle before, it was called 8.2. It
>> fails, remarkably.
> I think this is a bit of revisionsit history.
JD got the release number wrong, it was 8.3, but otherwise there's no
rev
On Tue, 27 Jan 2009, Chad Sellers wrote:
I'll speak to this a bit (Josh is also a Tresys employee). I can't say who
my customers are, but I can speak to their needs. They really need row-level
mandatory access controls (so both).
From the perspective of what this would buy as far as this featu
Robert Treat writes:
> Now I am starting to think that we cannot prevent large patches from showing
> up at the end of a cycle no matter what, and the only way to really "solve"
> that problem is to lesson the pain of getting bumped from a release. Ie.
> instead of being bump meaning you must w
On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
> On Tue, 2009-01-27 at 06:40 +0100, Pavel Stehule wrote:
> > > 8.4-stable
> > > 8.4-experimental
> > >
> > > stable is everything that stable is. PostgreSQL at its best.
> >
> > I dislike this idea - it's same like short processed 8.5 -
>
On 1/27/09 4:40 PM, "Ron Mayer" wrote:
> Joshua Brindle wrote:
>>> FWIW, as you know, sepostgresql is already included in Fedora. You can
>>> continue shipping it as a seperate RPM set.
>>
>> That is non-ideal. Getting the capability in to the standard database
>> shipped with RHEL is very impor
That's modest. I've talked to several oracle and db2 shops that want a standby
for reporting that has relatively easy setup/maintenance (handling ddl is a
big part of this) and the HS feature your working on will give them something
as good as what they are getting now. So yeah, HS appeals to
On Tuesday 27 January 2009 11:56:51 Simon Riggs wrote:
> On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote:
> > David Fetter writes:
> > > On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote:
> > >> I don't think this is correct.
> > >
> > > I do.
> > >
> > > People literally grab my shoulder
Marko Kreen wrote:
> On 1/27/09, Peter Eisentraut wrote:
>> On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
>> > Such app already exists:
>> >
>> > http://ozlabs.org/~jk/projects/patchwork/
>> >
>> > So it's a matter of just setting it up.
>>
>>
>> I was in fact in the process of set
On Monday 26 January 2009 15:13:56 dp...@pgadmin.org wrote:
> On 1/26/09, Josh Berkus wrote:
> > All,
> >
> >>> 1) having the last CF on Nov. 1 was a mistake. That put us square in
> >>> the path of the US & Christian holidays during the critical integration
> >>> phase ..
> >>> which means we ha
Joshua Brindle wrote:
>> FWIW, as you know, sepostgresql is already included in Fedora. You can
>> continue shipping it as a seperate RPM set.
>
> That is non-ideal. Getting the capability in to the standard database
> shipped with RHEL is very important to me and my customers.
Could you speak -
On Mon, Jan 26, 2009 at 08:28:32PM -0500, Tom Lane wrote:
> Hmm, you think selinux people read pgsql-announce?
Maybe not, but it got it onto LWN, which is a lot more people.
Have a nice day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> Please line up in a tree and maintain the he
On Tue, 2009-01-27 at 15:46 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Not to pick on you personally, but this is the kind of review that should
> > have
> > happened six months ago, not during a "why is our development process
> > inadequate" discussion on the eve of beta.
>
> Rig
* Devrim GÜNDÜZ (dev...@gunduz.org) wrote:
> On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote:
> > With my other hat on (the red one) what I'm concerned about is whether
> > this patch will ever produce a feature that I could turn on in the
> > standard Red Hat/Fedora build of Postgres.
>
> FWIW
Devrim GÜNDÜZ wrote:
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote:
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres.
FWIW, as you know, sepostgresql is alrea
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote:
>
> With my other hat on (the red one) what I'm concerned about is whether
> this patch will ever produce a feature that I could turn on in the
> standard Red Hat/Fedora build of Postgres.
FWIW, as you know, sepostgresql is already included in F
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Personally, I think it'd be terrible to implement the suggestion that
> > started this sub-thread since it breaks with what is currently done
> > elsewhere and what the users of this feature would expect.
>
> Upthread we were bein
Tom Lane wrote:
Stephen Frost writes:
Personally, I think it'd be terrible to implement the suggestion that
started this sub-thread since it breaks with what is currently done
elsewhere and what the users of this feature would expect.
Upthread we were being told that this patch breaks new gro
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> BTW, whilst we are being beat about the head and shoulders with how
> Oracle et al already have features like this, it is entirely appropriate
> to wonder how come it's not in the standard. Those companies surely
> pretty much control the standards committe
On 1/27/09, Peter Eisentraut wrote:
> On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
> > Such app already exists:
> >
> > http://ozlabs.org/~jk/projects/patchwork/
> >
> > So it's a matter of just setting it up.
>
>
> I was in fact in the process of setting that up just now. :-)
Ni
Stephen Frost writes:
> Personally, I think it'd be terrible to implement the suggestion that
> started this sub-thread since it breaks with what is currently done
> elsewhere and what the users of this feature would expect.
Upthread we were being told that this patch breaks new ground and will
o
Peter Eisentraut writes:
> On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote:
>> The SQL spec doesn't define row-level security, and coming
>> up with something willy-nilly on our own doesn't really strike me as the
>> best approach.
> Exactly. But there is plenty of discussion on that el
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > Not to pick on you personally, but this is the kind of review that should
> > have
> > happened six months ago, not during a "why is our development process
> > inadequate" discussion on the eve of beta.
>
> Right now, today
* Peter Eisentraut (pete...@gmx.net) wrote:
> > The SQL spec doesn't define row-level security, and coming
> > up with something willy-nilly on our own doesn't really strike me as the
> > best approach.
>
> Exactly. But there is plenty of discussion on that elsewhere.
That's the nice thing abou
Peter Eisentraut writes:
> Not to pick on you personally, but this is the kind of review that should
> have
> happened six months ago, not during a "why is our development process
> inadequate" discussion on the eve of beta.
Right now, today, in this thread, is the first time that we've had an
On Tuesday 27 January 2009 19:10:40 Gregory Stark wrote:
> It does seem weird to simply omit records rather than throw an error and
> require the user to use a where clause, even if it's something like WHERE
> pg_accessible(tab).
Not to pick on you personally, but this is the kind of review that s
Tom Lane wrote:
Ron Mayer writes:
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
policies that
Ron Mayer writes:
> Tom Lane wrote:
>> This seems to me to be exactly parallel to deciding that SELinux should
>> control only table/column permissions within SQL; an approach that would
>> be enormously less controversial, less expensive, and more reliable than
>> what SEPostgres tries to do.
>
1 - 100 of 257 matches
Mail list logo
