Tom Lane wrote:
Robert Haas writes:
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got.
And we won't ever have, because it's unnecessary and would be impossibly
complex. We know how to do the catalog update: basically,
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 Wednesday 28 January 2009 07:05:17 Robert Haas wrote:
> Easy to do with git.
>
> $ git log
>
> Use "/Allow AS" to find the commit. Oh, there it is.
>
> $ git log -1 -p 4f08d8492598a518f803d8c2979b39f0050b0f8d > allow-as.patch
>
> Attached for your convenience. :-)
More compactly, git show $HA
Robert Haas wrote:
Easy to do with git.
$ git log
Use "/Allow AS" to find the commit. Oh, there it is.
$ git log -1 -p 4f08d8492598a518f803d8c2979b39f0050b0f8d > allow-as.patch
Attached for your convenience. :-)
Please don't post patches for private use on the list.
cheers
andrew
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
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
I've installed drmingw to handle exceptions instead, so we'll see if
that gives us useful info. If not, I'll see what I can do with gdb.
Hadn't heard of drwmingw, I see how that can be useful :-)
report from
On Tue, 27 Jan 2009, Robert Haas wrote:
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got.
Right, and designing such a system requires a fairly deep analysis of the
catalog changes that have historically shown up, to m
On Wed, Jan 28, 2009 at 12:05 AM, Robert Haas wrote:
> Easy to do with git.
>
> $ git log
>
> Use "/Allow AS" to find the commit. Oh, there it is.
>
> $ git log -1 -p 4f08d8492598a518f803d8c2979b39f0050b0f8d > allow-as.patch
>
> Attached for your convenience. :-)
>
thanks, i will have to start
Easy to do with git.
$ git log
Use "/Allow AS" to find the commit. Oh, there it is.
$ git log -1 -p 4f08d8492598a518f803d8c2979b39f0050b0f8d > allow-as.patch
Attached for your convenience. :-)
...Robert
commit 4f08d8492598a518f803d8c2979b39f0050b0f8d
Author: Tom Lane
Date: Fri Feb 15 22:1
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
>
Robert Haas writes:
> That implies a fairly robust and configurable system for adding to and
> rewriting system catalogs, which today we haven't got.
And we won't ever have, because it's unnecessary and would be impossibly
complex. We know how to do the catalog update: basically, dump, initdb,
r
Hi,
I want to put the patch for "Allow AS to be omitted when specifying an
output column name" [1] in 8.3.5 because i'm doing a migration and
need that (for avoiding large changes in application) before May 1st,
because is only 2 .y files i tried to just copy 'n paste but the links
doesn't work.
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
> for getting 8.4->8.5 upgrade into place. You should first work on an
> update process that supports catalog changes, and get that committed.
> Once that's in place you'll have enough political capital to prevent
> changes in user data layout, and then we'd start to think about schemes
> like spa
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
>> I thought we pretty much had agreement that space reservation was not
>> a good solution to anything, although I admit I'm not quite clear on
>> what alternative was being proposed.
>
> Maybe I miss something, but space reservation was selected as a best
> way. Please, Could you point me related
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
Timo Savola escreveu:
> Hello. The attached patch has made it more feasible for us to gather
> profiling data on a production system for analysis with pgFouine. It
> has been written against PostgreSQL 8.3.5 and tested on Linux. Comments
> welcome.
>
IIRC pgFouine shows exact percentage of quer
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 Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
> I'm doing some test runs with this now. I notice an old flatfiles
> related bug has reappeared:
Bug fix patch against git repo.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
*** a/src/backend/
Caleb Welton writes:
> Two child tables, one created with inheritance, one altered to have
> inheritance:
> When you drop a column from the parent table only the tables CREATED with
> inheritance drop the column:
Yeah, this is intentional. The other table is presumed to still own its
columns eve
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
Hello,
I'm trying to figure out if this is a bug or a feature.
Two child tables, one created with inheritance, one altered to have
inheritance:
create table A(a text, b text);
create table A1() inherits (A);
create table A2(a text, b text);
alter table A2 INHERIT A;
When you dro
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
On Tue, Jan 27, 2009 at 3:36 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On Tuesday 27 January 2009 17:19:28 Tom Lane wrote:
>>> It's a potential security hole, since GRANT ALL on a view used to
>>> be de facto the same as GRANT SELECT, if you hadn't bothered to
>>> create any rules.
>
>> T
* 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
Peter Eisentraut writes:
> On Tuesday 27 January 2009 16:52:15 Tom Lane wrote:
>> Indeed. We might put up with a perl script for awhile for the sake of
>> development expediency, but the long-term expectation would have to be
>> that someone would rewrite it in C. Given that, I wonder whether
>>
* 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 Tuesday 27 January 2009 23:02:30 Dave Page wrote:
> On Tue, Jan 27, 2009 at 8:54 PM, Peter Eisentraut wrote:
> > On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
> >> If it's been around for a year, why hasn't it been
> >> submitted long ago so we could have rewritten and reviewed etc. in
>
On Tue, 2009-01-27 at 15:09 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 27, 2009 at 1:50 PM, Jeff Davis wrote:
> >> I think both of these deserve at least a glance by a committer before
> >> bouncing them.
>
> > While we're at it, I think the Ramon Lawrence/Bryce Cutt patch to
>
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
On Tue, 27 Jan 2009, Peter Eisentraut wrote:
On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
If it's been around for a year, why hasn't it been
submitted long ago so we could have rewritten and reviewed etc. in
plenty of time?
It's in the commit fest listing, and the discussion about whi
On Tuesday 27 January 2009 17:27:32 Kaare Rasmussen wrote:
> Hi
>
> > I have had a very brief look at this. Translation to perl doesn't look
> > difficult. I'll see what I can do during the next week or so.
>
> Perhaps I can lend you a hand if you need help with this.
Not to stop you are anything,
On Tue, Jan 27, 2009 at 8:54 PM, Peter Eisentraut wrote:
> On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
>> If it's been around for a year, why hasn't it been
>> submitted long ago so we could have rewritten and reviewed etc. in
>> plenty of time?
>
> It's in the commit fest listing, and th
On Tuesday 27 January 2009 16:54:02 Magnus Hagander wrote:
> Either way, there's no point to discuss that in detail until there
> actually is a working implementation out there... perl will do fine
> until then
There is a working implementation out there. It is -- you guessed it --
sitting in th
On Tuesday 27 January 2009 16:52:15 Tom Lane wrote:
> Indeed. We might put up with a perl script for awhile for the sake of
> development expediency, but the long-term expectation would have to be
> that someone would rewrite it in C. Given that, I wonder whether
> there's much point in a rewrite
On Tue, Jan 27, 2009 at 8:52 PM, Zdenek Kotala wrote:
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg01051.php
>
> But you can read there that it is korn shell script and there is link to
> it.
OK, yes that does mention it. It's not exactly clear that it's
something you wanted to inc
On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
> If it's been around for a year, why hasn't it been
> submitted long ago so we could have rewritten and reviewed etc. in
> plenty of time?
It's in the commit fest listing, and the discussion about which programming
language to port it to happe
Magnus Hagander wrote:
Andrew Dunstan wrote:
I've installed drmingw to handle exceptions instead, so we'll see if
that gives us useful info. If not, I'll see what I can do with gdb.
Hadn't heard of drwmingw, I see how that can be useful :-)
report from DrMingw is below
cheer
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
Dave Page píše v út 27. 01. 2009 v 20:36 +:
> On Tue, Jan 27, 2009 at 8:31 PM, Zdenek Kotala wrote:
> >>
> >> Neither of which are the correct place to submit work for inclusion in
> >> PostgreSQL.
> >
> > http://archives.postgresql.org/pgsql-hackers/2008-04/msg00990.php
> >
> > I sent it in
* 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 Tue, Jan 27, 2009 at 8:31 PM, Zdenek Kotala wrote:
>
> Dave Page píše v út 27. 01. 2009 v 19:36 +:
>> On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala wrote:
>> >
>> > Dave Page píše v út 27. 01. 2009 v 14:56 +:
>> >> I'd rather it was written in an appropriate language before feature
>>
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
Peter Eisentraut writes:
> On Tuesday 27 January 2009 17:19:28 Tom Lane wrote:
>> It's a potential security hole, since GRANT ALL on a view used to
>> be de facto the same as GRANT SELECT, if you hadn't bothered to
>> create any rules.
> That is a good point. But the only clean solution would be
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.
>
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 accomplished in terms of reacting to
Dave Page píše v út 27. 01. 2009 v 19:36 +:
> On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala wrote:
> >
> > Dave Page píše v út 27. 01. 2009 v 14:56 +:
> >> I'd rather it was written in an appropriate language before feature
> >> freeze, not in a language that makes it easier for the auth
On Tuesday 27 January 2009 16:48:21 Sam Mason wrote:
> > though at EAL1 they're quite far from the EAL4+ that DB2,
> > Oracle, etc get.
>
> As far as I understand, the different levels are about assuring a
> set of code/features to some assurance level. The Wikipedia page[1]
> gives a reasonable o
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. :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Tuesday 27 January 2009 17:19:28 Tom Lane wrote:
> If we'd had the SQL-spec behavior from day one, it wouldn't be a
> problem, but you can't just blow off the old behavior like that.
> It's a potential security hole, since GRANT ALL on a view used to
> be de facto the same as GRANT SELECT, if yo
On Tue, 2009-01-27 at 22:12 +0200, Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
> > On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
> >
> >> And last I think license is not BSD, I don't know how big problem it is.
> >
> > Uhh.. that kills it. We only accept BSD.
>
> Actually, it ha
Tom Lane wrote:
Simon Riggs writes:
On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote:
Josh Berkus wrote:
Hmmm. Why try to hide individual rows in tables then? That would seem
not in keeping with the filesystem policies.
Because rows have data in them. It is analogous to not allowing
Joshua D. Drake wrote:
On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
And last I think license is not BSD, I don't know how big problem it is.
Uhh.. that kills it. We only accept BSD.
Actually, it has been relicensed to BSD license, after a short
discussion started by Bruce within
Joshua D. Drake wrote:
On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
And last I think license is not BSD, I don't know how big problem it is.
Uhh.. that kills it. We only accept BSD.
Actually, that was just fixed. Once somebody raised the issue, EDB
changed the license (there ha
Robert Haas writes:
> On Tue, Jan 27, 2009 at 1:50 PM, Jeff Davis wrote:
>> I think both of these deserve at least a glance by a committer before
>> bouncing them.
> While we're at it, I think the Ramon Lawrence/Bryce Cutt patch to
> "Improve Performance of Multi-Batch Hash Join for Skewed Data
Simon Riggs writes:
> On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote:
>> Josh Berkus wrote:
>>> Hmmm. Why try to hide individual rows in tables then? That would seem
>>> not in keeping with the filesystem policies.
>>
>> Because rows have data in them. It is analogous to not allowing
> 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
> level permissio
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 produce b
On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
> And last I think license is not BSD, I don't know how big problem it is.
Uhh.. that kills it. We only accept BSD.
Joshua D. Drake
>
> Zdenek
>
>
>
>
--
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
Consulting, Developmen
Heikki Linnakangas píše v út 27. 01. 2009 v 21:37 +0200:
> Zdenek Kotala wrote:
> > Set general value for heap or btree is possible but not optimal. For
> > example If you have 5TB table and page layout changes do not affected
> > this table but some small table needs perform a cleanup then 5TB w
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 it wasn't clear to me t
Tom Lane píše v út 27. 01. 2009 v 14:31 -0500:
> Zdenek Kotala writes:
> > Merlin Moncure píše v út 27. 01. 2009 v 09:47 -0500:
> >> Just to clarify, does that mean that your patch has to be in for there
> >> to be any chance of in-place upgrade 8.4->8.5?
>
> > Ok, There two patch in the queue f
* 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 it wasn't clear to me that the PGACE bits
Tom Lane wrote:
>> We do not consider that a short coming, anyone who needs to hide
>> existence of files needs to set up their directory structure to
>> disallow read/search/create on the directories they aren't allowed to
>> discover filenames in.
>
> This seems to me to be exactly parallel to d
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 magnitude.
> Well, look at i
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 not an issue for us.
>
> Yes it is a
On Tue, Jan 27, 2009 at 2:18 PM, 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;
Ron Mayer wrote:
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(tab).
It is weird from an SQL perspective, I ag
1 - 100 of 274 matches
Mail list logo
