Hi,
On Tue, Feb 3, 2009 at 5:08 AM, Bruce Momjian br...@momjian.us 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
I understand Simon is extremely busy on his own patch. I appreciate
if anyone help the review.
2009/2/6 Fujii Masao masao.fu...@gmail.com:
Hi,
On Tue, Feb 3, 2009 at 5:08 AM, Bruce Momjian br...@momjian.us wrote:
o Others
We will focus on all the other items on the commit fest
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 on
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
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.
So
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 in
Magnus Hagander wrote:
On 29 jan 2009, at 05.35, Bruce Momjian br...@momjian.us wrote:
Peter Eisentraut wrote:
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen
Stefan Kaltenbrunner wrote:
Magnus Hagander wrote:
On 29 jan 2009, at 05.35, Bruce Momjian br...@momjian.us wrote:
Peter Eisentraut wrote:
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27
Magnus Hagander wrote:
Stefan Kaltenbrunner wrote:
Magnus Hagander wrote:
On 29 jan 2009, at 05.35, Bruce Momjian br...@momjian.us wrote:
Peter Eisentraut wrote:
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut pete...@gmx.net
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
Robert Haas robertmh...@gmail.com 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
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
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 the
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
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 my
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
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 with
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
Josh Berkus j...@agliodbs.com 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
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 I
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 everyone
Peter Eisentraut wrote:
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote:
Marko Kreen wrote:
On 1/27/09, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
Such app already exists:
http://ozlabs.org/~jk/projects/patchwork/
-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 pete...@gmx.net wrote:
On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote:
Such app
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
On Wed, Jan 28, 2009 at 4:28 AM, Peter Eisentraut pete...@gmx.net 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
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...
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 now. So
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
Magnus Hagander mag...@hagander.net 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
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
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 finished
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
Robert Treat xzi...@users.sourceforge.net 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
Le 28 janv. 09 à 16:22, Simon Riggs si...@2ndquadrant.com 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
Dimitri Fontaine dfonta...@hi-media.com writes:
Le 28 janv. 09 à 16:22, Simon Riggs si...@2ndquadrant.com 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
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 Others
You omit
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
On Wednesday 28 January 2009 12:35:42 Tom Lane wrote:
Robert Treat xzi...@users.sourceforge.net 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,
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us 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
Simon Riggs wrote:
On Tue, 2009-01-27 at 14:18 -0500, Tom Lane wrote:
Joshua Brindle met...@manicmethod.com 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
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 whether
Bruce Momjian br...@momjian.us 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
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 accomplished
Simon Riggs wrote:
On Tue, 2009-01-27 at 15:46 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
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 with
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 with), or his
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 about
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 here is to
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
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
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-PostgreSQL has been in steady
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 they're
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
Then why has *nobody* stepped up to review the design, much less the
whole patch? The plain truth is that no one appears to care enough to
expend any real effort.
I've spent some time looking at it and have made all the comments I
wished to
Dave Page wrote:
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct.
On Jan 27, 2009, at 2:41 AM, Mark Kirkwood wrote:
Dave Page wrote:
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
SEPostgres seems qualitatively different to me, though. I think PG
people have avoided reviewing it because (a) they weren't interested in
it and (b) they knew they were unqualified to review it.
Meanwhile it's emerging that the selinux people don't
Simon Riggs wrote:
On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
Then why has *nobody* stepped up to review the design, much less the
whole patch? The plain truth is that no one appears to care enough to
expend any real effort.
I've spent some time looking at it and have made all
On Tuesday 27 January 2009 00:42:32 Ron Mayer wrote:
If it were just as easy for us to pull from a
all 'pending-patches' for-commit-fest-nov that pass regression tests
branch, I'd happily pull from that instead.
Considering that most patches don't come with regression tests, this would
Robert Haas escribió:
I think that it would probably be pretty easy to write a webapp to
replace the CommitFest web page that basically did the same thing but
with a bit more structure around it - with database tables like
commitfest, patch, patch_version, patch_comment, and
patch_review. I
On Tue, Jan 27, 2009 at 1:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
As for somewhere to host it, we certainly have some servers; not tons,
but probably enough. Some of them even have Postgres running on it.
We can certainly host an app under postgresql.org. The bigger issue
will
Dave Page wrote:
On Tue, Jan 27, 2009 at 1:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
As for somewhere to host it, we certainly have some servers; not tons,
but probably enough. Some of them even have Postgres running on it.
We can certainly host an app under postgresql.org.
On 1/27/09, Alvaro Herrera alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I think that it would probably be pretty easy to write a webapp to
replace the CommitFest web page that basically did the same thing but
with a bit more structure around it - with database tables like
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 Others
You omit pg_upgrade. Does it mean that
On Tuesday 27 January 2009 02:21:41 Tom Lane wrote:
Then why has *nobody* stepped up to review the design, much less the
whole patch? The plain truth is that no one appears to care enough to
expend any real effort. But this patch is far too large and invasive
to accept on the basis that only
Simon Riggs wrote:
The process works like this: software gets developed, then it gets
certified. If its not certified, then Undercover Elephant will not be
used by the secret people. We can't answer the will it be certified?
question objectively yet. If we have someone willing to write the
I have started some very trivial work around this a while ago with the
intent to get something simple up and working before too much bike
shedding is done. I'll contact Robert off-list to discuss that. If
somebody else - who actively works with what we have now!! - is
interested in that
Peter Eisentraut wrote:
On Tuesday 27 January 2009 00:42:32 Ron Mayer wrote:
If it were just as easy for us to pull from a
all 'pending-patches' for-commit-fest-nov that pass regression tests
branch, I'd happily pull from that instead.
Considering that most patches don't come with
Peter,
* 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 our comments. For example, where is the
SQL row
On Tue, Jan 27, 2009 at 06:20:41AM -0800, Ron Mayer wrote:
For what it's worth, we can see that there are indeed
Postgres forks on the Common Criteria certified list.
http://www.commoncriteriaportal.org/products_DB.html
PostgreSQL Certified Version V8.1.5 for Linux
Manufacturer
Tom Lane wrote:
Joshua Brindle met...@manicmethod.com writes:
http://marc.info/?l=selinuxm=115762285013528w=2
Is the original discussion thread for the security model used in the
sepostgresql work. Hopefully you'll see some of the evidence you speak of there.
Thanks for the link. I took a
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
SEPostgres seems qualitatively different to me, though. I think PG
people have avoided reviewing it because (a) they weren't interested in
it and (b) they knew they were unqualified to review it.
Meanwhile it's emerging that the
On Wed, Jan 28, 2009 at 1:35 AM, Robert Haas robertmh...@gmail.com wrote:
I have started some very trivial work around this a while ago with the
intent to get something simple up and working before too much bike
shedding is done. I'll contact Robert off-list to discuss that. If
somebody else -
I think it's possible to skip the roll our own step in all of this
and just move on to using a ready-made solution. In reality our
requirements are very simple. Writing a low-fi version of the wiki
would be pretty easy, but just dropping the patch data we already have
into a patch tracker
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 -
Actually it isn't because we wouldn't accept features into
8.4-experimental.
On Tue, 2009-01-27 at 00:58 -0500, Jaime Casanova wrote:
On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
so it could be released. 8.5 should be implemented in shorted
cycle - only one commitfest, that is enough (+3 month) for well
completing SE and
On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct.
I do.
People literally grab my shoulder and
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like an
On Mon, 2009-01-26 at 22:55 -0500, Tom Lane wrote:
Silently filtering out rows according to an arbitrary security policy
can break a bunch of fundamental SQL semantics, the most obvious being
foreign key constraints
That was exactly my reaction when I read the way it worked and I was
ready
On Tue, 2009-01-27 at 10:51 -0500, Tom Lane wrote:
Without an integrated and fairly high-performance log
shipping capability, they are not going to find HS very compelling.
Claiming otherwise is just wishful thinking.
What HS will give us is same or better than the equivalent feature in
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-01-26 at 22:55 -0500, Tom Lane wrote:
Silently filtering out rows according to an arbitrary security policy
can break a bunch of fundamental SQL semantics, the most obvious being
foreign key constraints
That was exactly my reaction when
Yeah, people like certification, but they also like products that work.
Did you stop reading before getting to my non-security-based complaints?
I read them, but I suspect they are issues that can be addressed. How
would any of this affect join removal, anyway? At most it would
affect join
David Fetter da...@fetter.org 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 and ask when we'll have it.
Do these people understand the difference between HS and a complete
replication solution? Are
On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote:
David Fetter da...@fetter.org 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 and ask when we'll have it.
Do these people understand the
On Tue, 2009-01-27 at 11:26 -0500, Tom Lane wrote:
Yeah, people like certification, but they also like products that work.
Did you stop reading before getting to my non-security-based complaints?
Yes, I'm sorry, I did. Will read on.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
Robert Haas robertmh...@gmail.com writes:
Yeah, people like certification, but they also like products that work.
Did you stop reading before getting to my non-security-based complaints?
I read them, but I suspect they are issues that can be addressed. How
would any of this affect join
On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote:
David Fetter da...@fetter.org 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 and ask when we'll have it.
Do these people understand the
Joshua D. Drake j...@commandprompt.com writes:
This is my take as well. This is very real, very scary things that are
being worked on. HS should only ship after a very, very long non change
cycle (meaning no significant bugs (or refactoring) found in HS patch
for X period of time)... say
On Tue, Jan 27, 2009 at 11:36:02AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org 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 and ask when we'll have it.
Do these people understand
Brendan Jurd dire...@gmail.com writes:
I think the picture has started to become more clear during the 8.4
dev cycle. Most importantly, there was much ado made about the need
for powerful email integration features in previous discussions. This
severely restricted our choices (possibly to
On Mon, 2009-01-26 at 22:55 -0500, Tom Lane wrote:
Even accepting such a restriction, there's too much code in
core Postgres to let anyone feel very good about keeping the core free
of security leaks
I see what you're saying, but we're trying to pass certification, not
provide security in all
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
Yeah, people like certification, but they also like products that work.
Did you stop reading before getting to my non-security-based complaints?
I read them, but I suspect they are issues that can be addressed.
On Tue, 2009-01-27 at 11:49 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, people like certification, but they also like products that work.
Did you stop reading before getting to my non-security-based complaints?
I read them, but I suspect they are issues that
* 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 agree with you there. On the
other
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It would prevent us from making optimizations that assume foreign key
constraints hold; which is a performance issue not a covert-channel
issue.
Oh, I see now. That problem is
On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, people like certification, but they also like products that work.
Did you stop reading before getting to my non-security-based complaints?
I read them, but I suspect they are
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(tab).
[…]
do
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).
The idea is for the level of informations security we're
Josh Berkus j...@agliodbs.com writes:
Stephen Frost wrote:
It does seem weird to simply omit records rather than throw an error
The presumption is that if you know the data exists but can't access it
directly, you'll use indirect methods to derive what it is. But if you
don't even know it
1 - 100 of 257 matches
Mail list logo
