KaiGai Kohei wrote:
How frequently does someone want to *work* (not compile) DAC and MAC
in same time?
My expectation would be Always.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?
This would effectively create a limit on the number of rows per table.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based
row access control at the same tim
Hello,
As per title, what is the lifetime of the virtual tuple TupleTableSlot*
returned by ExecProcNode?
Any help would be appreciated.
Regards,
Bramandia R.
On Fri, Dec 12, 2008 at 9:08 AM, Koichi Suzuki wrote:
> Hmmm, it's really like pg_readahead needs to be included in the core.
> I don't think it's a big work and will try to do this.
>
Yes, I think it's best to have it in core. I would actually combine it
with the other idea of reading xlog fi
Bruce Momjian wrote:
Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?
The reason why I decided to put an integer value on HeapTupleHeader,
as "oid" doing, is that it has to be modified after simple_heap_i
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > We have had discussion on whether we want one or two security columns;
> > there have been comments on both sides.
>
> It is quite natural end-user should be able to choose one of provided
> security mechanisms, in my opinion. It means user (administ
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > In general, I am concerned that the SE-Linux patch is not converging on
> > a community consensus in terms of user interface or implementation
> > details. This suggests that the patch might not succeed in being
> > included in Postgres 8.4, which is
Bruce Momjian wrote:
In general, I am concerned that the SE-Linux patch is not converging on
a community consensus in terms of user interface or implementation
details. This suggests that the patch might not succeed in being
included in Postgres 8.4, which is a shame.
It is extreamly worst.
I
Bruce Momjian wrote:
We have had discussion on whether we want one or two security columns;
there have been comments on both sides.
It is quite natural end-user should be able to choose one of provided
security mechanisms, in my opinion. It means user (administrator) allows
his prefered securit
* Fujii Masao [081211 23:00]:
> Hi,
> Or, should I
> create the feature for the user to confirm whether it's in "synch rep" via
> SQL?
I don't need a way to check via SQL, but I'ld love a postgresql.conf
option that when set would ma
Hi,
> The idea is that we would be able to have multiple standby servers
> connecting to one primary, yes? It would be useful to have sync
> replication work that it must get an acknowledgement from at least one
> standby before it continues.
No, in my current patch, only one standby can perform
Hello,
Michael Meskes wrote:
> Could anyone with a MinGW system please run the ecpg regression suite
> including
> tcp checks for the current CVS HEAD for me?
I ran the test but got a segfault.
I hope it can help you.
$ make checktcp NO_LOCALE=on
== running regression test queries
Hi,
On Fri, Dec 12, 2008 at 12:15 AM, Aidan Van Dyk wrote:
> * Heikki Linnakangas [081211 10:09]:
>> Simon Riggs wrote:
>>> On Thu, 2008-12-11 at 09:27 -0500, Aidan Van Dyk wrote:
>>>
But "catchup" *has* to be *done* before PostgreSQL can enter "sync rep".
>>>
>>> Not true. Please reread th
We have had discussion on whether we want one or two security columns;
there have been comments on both sides.
Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?
If we use some type of integer, I suggest us
In general, I am concerned that the SE-Linux patch is not converging on
a community consensus in terms of user interface or implementation
details. This suggests that the patch might not succeed in being
included in Postgres 8.4, which is a shame.
We are going to need to come up with specific ans
Hmmm, it's really like pg_readahead needs to be included in the core.
I don't think it's a big work and will try to do this.
2008/12/9 Fujii Masao :
> Hi,
>
> On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki wrote:
>> I understood your point. In the case of synchronous replication,
>> because s
Tom Lane wrote:
if we fix some or all of the headers, what's the
plan for making sure that they stay fixed? Without a C++ buildfarm
member I think the chances of future breakage approach certainty.
Actually, after re-reading the whole earlier thread I see that we did
think of a possible answer
Peter Eisentraut wrote:
> On Thursday 11 December 2008 20:32:25 Tom Lane wrote:
> > Well, the objection I was raising is that they should control the same
> > thing. Otherwise we are simply inventing an invasive, high-cost,
> > nonstandard(*) feature that we have had zero field demand for.
>
> Th
"Robert Haas" writes:
> I had this idle thought too, but I didn't write it down because...
>> ought to be, but it seems like it ought to be possible to determine
>> that given a desired maximum error in the overall estimate. I'm also
>> not very clear on what the "total frequency" computations (
> This idea allows to compile two or more security mechanism in the same binary,
> and adds a configuration parameter to choose a security mechanism on its
> startup
> time. So, a single security mechanism chosen works in same time, but multiple
> security mechanisms are built in compile time.
Th
>> OK, I'll bite. How do we decide where to put the cutoff? If we make
>> it too high, it will have a negative effect on join selectivity
>> estimates; if it's too low, it won't really address the problem we're
>> trying to fix. I randomly propose p = 0.001, which should limit
>> eqjoinsel() to
>> Isn't a selectivity estimate of x = v as ( the number of values in v's
>> histogram bucket ) / ( number of distinct values in v's histogram
>> bucket ) pretty rational? Thats currently what we do for non-mcv
>> values, except that we look at ndistinct over the whole table instead
>> of individua
Tom Lane wrote:
Given the above constraints, I think the only real role for C++ here
would be to allow access to third-party C++ libraries as Postgres
extensions --- for instance something like an XML or numerical analysis
I seem to recall that we're already able to do this.
IIRC, some older
On Thu, Dec 11, 2008 at 11:44 PM, Simon Riggs wrote:
>
> On Thu, 2008-12-11 at 22:29 +, Gregory Stark wrote:
>
>> > And I would like it even more if the sample size increased according
>> to table size, since that makes ndistinct values fairly random for
>> large
>> > tables.
>>
>> Unfortunate
"Robert Haas" writes:
>> It might be best to stop when the frequency drops below some threshold,
>> rather than taking a fixed number of entries.
> OK, I'll bite. How do we decide where to put the cutoff? If we make
> it too high, it will have a negative effect on join selectivity
> estimates;
KaiGai Kohei wrote:
I understood objections for "enable/disable something on compile-time"
approach. The following items are my revised proposal.
It does not conflicts to the policy Peter said before in this thread.
Items to be revised:
- It allows to compile multiple security mechanis within a
I wrote:
> The stumbling block, though, remains the same as I mentioned in the
> message you linked to: if we fix some or all of the headers, what's the
> plan for making sure that they stay fixed? Without a C++ buildfarm
> member I think the chances of future breakage approach certainty.
Actuall
I understood objections for "enable/disable something on compile-time"
approach. The following items are my revised proposal.
It does not conflicts to the policy Peter said before in this thread.
Items to be revised:
- It allows to compile multiple security mechanis within a single binary.
- It
> I think though that the case for doing so is pretty good. "MCVs" that
> are beyond the K'th entry can't possibly have frequencies greater than
> 1/K, and in most cases it'll be a lot less. So the incremental
> contribution to the accuracy of the join selectivity estimate drops off
> pretty quic
"Nathan Boley" writes:
> Isn't a selectivity estimate of x = v as ( the number of values in v's
> histogram bucket ) / ( number of distinct values in v's histogram
> bucket ) pretty rational? Thats currently what we do for non-mcv
> values, except that we look at ndistinct over the whole table ins
Thanks for the response.
>> Well, ISTM there is a profound difference. For scalarineqsel we care
>> about the total number of values in a bucket. For eqsel we care about
>> the total number of *distinct* values in each bucket
>
> Really?
>
Well, we would obviously also care about the total numbe
Kurt Harriman writes:
> Suppose we were to use the C++ compiler to build all of
> PostgreSQL. Consider the alternatives: either
>A) switch over entirely to C++, no longer supporting C; or
>B) let the build farm do a nightly build with a C++ compiler
> merely as a test to verify t
KaiGai Kohei wrote:
Gregory Stark wrote:
Peter Eisentraut writes:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based
row access
Gregory Stark wrote:
Peter Eisentraut writes:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same t
Is there anything in the source that would necessarily preclude using the
C++ compiler to build *all* the code?
No. Most of the source files would need a sprinkling of
tiny changes: typically only a handful of casts need to be
added. Some files would need more widespread (but still
trivial) ch
Peter Eisentraut wrote:
On Thursday 11 December 2008 20:32:25 Tom Lane wrote:
Well, the objection I was raising is that they should control the same
thing. Otherwise we are simply inventing an invasive, high-cost,
nonstandard(*) feature that we have had zero field demand for.
There is certain
Aidan Van Dyk wrote:
> Simlarly, SElinux is going to be used *on top* of any application that's
> out there, to try and enfoce the "no data coming in from a secure input"
> leaves through a "less secure output", irrespective of what app level
> security (and in this case, app-level being the SQL/SC
"Nathan Boley" writes:
> Well, ISTM there is a profound difference. For scalarineqsel we care
> about the total number of values in a bucket. For eqsel we care about
> the total number of *distinct* values in each bucket
Really?
> IMHO, the whole idea of increasing mcv's seems a mistake. Why no
>> What is the specific difference between what you are talking about and
>> what scalarineqsel already implements?
>
> Hmm... Northing new. Feel sorry for bothering you. I did not realize
> histograms are implemented.
>
Well, ISTM there is a profound difference. For scalarineqsel we care
about th
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same time. Isn't this exactl
KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it
should
be manipulable by either SQL commands or
Bruce Momjian writes:
> Why is selfuncs.c::var_eq_const() doing a linear scan over the MCV array
> instead of having the list sorted and doing a binary search on the
> array?
1. Keeping the MCV array sorted by frequency allows cheap extraction
of less-accurate MCV lists; you just take the first N
Simon Riggs writes:
> On Thu, 2008-12-11 at 22:29 +, Gregory Stark wrote:
>>> And I would like it even more if the sample size increased according
>>> to table size, since that makes ndistinct values fairly random for
>>> large tables.
>>
>> Unfortunately _any_ ndistinct estimate based on a s
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise y
Tom Lane wrote:
> "Robert Haas" writes:
> >> On the whole I think we have some evidence here to say that upping the
> >> default value of default_stats_target to 100 wouldn't be out of line,
> >> but 1000 definitely is. Comments?
>
> > Do you think there's any value in making it scale based on t
>>> Simon Riggs wrote:
> On Thu, 2008-12-11 at 17:45 -0500, Tom Lane wrote:
>> I don't see
>> much value in a data-type-dependent default anyway
I am dubious about the value there, too, at least for our environment.
> I would prefer distinct type or domain specific defaults
Now that would
On Thu, 2008-12-11 at 22:29 +, Gregory Stark wrote:
> > And I would like it even more if the sample size increased according
> to table size, since that makes ndistinct values fairly random for
> large
> > tables.
>
> Unfortunately _any_ ndistinct estimate based on a sample of the table
> is
Simon Riggs writes:
> On Thu, 2008-12-11 at 17:45 -0500, Tom Lane wrote:
>> Simon Riggs writes:
>>> I would like it even more if there was a data type specific default.
>>> Currently we have a special case for boolean, but that's it.
>>
>> No, we don't (or if we do I'd be interested to know wher
"Robert Haas" writes:
> On Thu, Dec 11, 2008 at 5:45 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> I would like it even more if there was a data type specific default.
>>> Currently we have a special case for boolean, but that's it.
>>
>> No, we don't (or if we do I'd be interested to know whe
On Thu, 2008-12-11 at 17:45 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > I would like it even more if there was a data type specific default.
> > Currently we have a special case for boolean, but that's it.
>
> No, we don't (or if we do I'd be interested to know where).
Your commit, selfun
On Thu, Dec 11, 2008 at 5:45 PM, Tom Lane wrote:
> Simon Riggs writes:
>> I would like it even more if there was a data type specific default.
>> Currently we have a special case for boolean, but that's it.
>
> No, we don't (or if we do I'd be interested to know where).
utils/adt/selfuncs.c, get
Gregory Stark writes:
> Tom Lane writes:
>> BTW, does anyone have an opinion about changing the upper limit for
>> default_stats_target to, say, 1? These tests suggest that you
>> wouldn't want such a value for a column used as a join key, but
>> I can see a possible argument for high values
Tom Lane writes:
> 500 114.076
> 600 157.535
> 700 211.189
> 800 269.731
> 900 335.427
> 1000 409.638
>...
> BTW, does anyone have an opinion about changing the upper limit for
> default_stats_target to, say, 1? These tests suggest that you
> wouldn't want such a value for a colu
>
> What is the specific difference between what you are talking about and
> what scalarineqsel already implements?
>
Hmm... Northing new. Feel sorry for bothering you. I did not realize
histograms are implemented.
Regards,
Vladimir Sitnikov
Simon Riggs writes:
> I would like it even more if there was a data type specific default.
> Currently we have a special case for boolean, but that's it.
No, we don't (or if we do I'd be interested to know where). I don't see
much value in a data-type-dependent default anyway --- would you make
Gregory Stark writes:
> Simon Riggs writes:
>> And I would like it even more if the sample size increased according to
>> table size, since that makes ndistinct values fairly random for large
>> tables.
> Unfortunately _any_ ndistinct estimate based on a sample of the table is going
> to be pret
Simon Riggs writes:
> On Thu, 2008-12-11 at 13:09 -0500, Tom Lane wrote:
>
>> On the whole I think we have some evidence here to say that upping the
>> default value of default_stats_target to 100 wouldn't be out of line,
>> but 1000 definitely is. Comments?
>
> Sounds good to me.
>
> I would li
"Vladimir Sitnikov" writes:
>> I think that would likely be redundant with the histogram.
>>
> I am afraid I do not get you.
AFAICS what you're proposing *is* a histogram, just awkwardly described.
What is the specific difference between what you are talking about and
what scalarineqsel already
On Thu, 2008-12-11 at 13:09 -0500, Tom Lane wrote:
> On the whole I think we have some evidence here to say that upping the
> default value of default_stats_target to 100 wouldn't be out of line,
> but 1000 definitely is. Comments?
Sounds good to me.
I would like it even more if there was a da
>
>
> I think that would likely be redundant with the histogram.
>
I am afraid I do not get you. I mean histograms should be considered when it
comes to increasing number of MCV entries (at least for numeric/timestamp
values). With histogram lower number of entries could be sufficient to get
reason
> One more direction could be implementing "MCV" for range of values (group
> values and interpolate in between). Consider statistics on timestamp column
> that says that for "2008-December" there are as many X rows, for
> "2008-November" as many as Y, etc. That could be used for rather accurate
>
Here's the update
I also skimmed through and cleaned a couple other things. There's *still* a
function prototype which I don't see what header file to put it in, that's the
one in port/posix_fadvise.c which contains one function with one caller, guc.c.
posix_fadvise_v23.diff.gz
Description: Bi
On Thu, 2008-12-11 at 19:19 +0900, Fujii Masao wrote:
> My new design of archiving is as follows.
So far I haven't asked about running multiple standby servers and don't
recall having seen this mentioned anywhere. Forgive me if this was
already mentioned.
The idea is that we would be able to ha
"Vladimir Sitnikov" writes:
> One more direction could be implementing "MCV" for range of values (group
> values and interpolate in between). Consider statistics on timestamp column
> that says that for "2008-December" there are as many X rows, for
> "2008-November" as many as Y, etc. That could
>
>
>
> There's something in what you say, but consider that we have pretty
> much unanimous agreement that 10 is too small. I think we should
> try to fix the problem, not just gradually ratchet up the value until
> people start complaining in the other direction. (Also, we should have
> plenty
On Thursday 11 December 2008 21:44:39 Gregory Stark wrote:
> > Because we want to use SQL-based row access control and SELinux-based row
> > access control at the same time. Isn't this exactly one of the
> > objections upthread? Both must be available at the same time.
>
> Well I don't think anyo
On Thursday 11 December 2008 20:32:25 Tom Lane wrote:
> Well, the objection I was raising is that they should control the same
> thing. Otherwise we are simply inventing an invasive, high-cost,
> nonstandard(*) feature that we have had zero field demand for.
There is certainly a rather big field
"Robert Haas" writes:
>> On the whole I think we have some evidence here to say that upping the
>> default value of default_stats_target to 100 wouldn't be out of line,
>> but 1000 definitely is. Comments?
> Do you think there's any value in making it scale based on the size of
> the table?
As
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 11 déc. 08 à 21:23, Tom Lane a écrit :
It's not that easy to produce a message that wouldn't be annoying
noise.
Something really amazing in PostgreSQL is the HINTs system in error
messages. Almost all the time thoses messages are focused and
Dimitri Fontaine writes:
>> The sanest answer I can see is "so, don't do that".
> Is there any warning level message at CREATE FUNCTION time for the
> user/dba to know he's doing something... border line, almost shooting
> himself in the foot?
It's not that easy to produce a message that wou
On Thu, Dec 11, 2008 at 2:06 PM, Tom Lane wrote:
> "Vladimir Sitnikov" writes:
>> Do you consider using hash tables?
>
> Doubt it's really worth it, unless there's some way to amortize the
> setup cost across multiple selectivity estimations; which would surely
> complicate life.
>
> One thing th
* Gregory Stark [081211 14:47]:
> Peter Eisentraut writes:
>
> > On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
> >> > How can we stick all of these in the same column at the same time?
> >>
> >> Why would we want to?
> >
> > Because we want to use SQL-based row access control and SELinux
Peter Eisentraut writes:
> On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
>> > How can we stick all of these in the same column at the same time?
>>
>> Why would we want to?
>
> Because we want to use SQL-based row access control and SELinux-based row
> access control at the same time. I
>
>
> > Do you consider using hash tables?
>
> Doubt it's really worth it, unless there's some way to amortize the
> setup cost across multiple selectivity estimations; which would surely
> complicate life.
>
MCV lists are updated only during "analyze" phase, don't they? If the "setup
cost" is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 11 déc. 08 à 16:22, Tom Lane a écrit :
Yeah, we already bit this bullet with variadic functions --- if you
have
myfunc(int, float)
myfunc(int, variadic float[])
then it's ambiguous which one should be used for call "myfunc(1
> When looking at these numbers one might think the threshold of pain
> is about 50, rather than 100 which is where I'd put it for the text
> example. However, this is probably an extreme worst case.
>
> On the whole I think we have some evidence here to say that upping the
> default value of defa
"Vladimir Sitnikov" writes:
> Do you consider using hash tables?
Doubt it's really worth it, unless there's some way to amortize the
setup cost across multiple selectivity estimations; which would surely
complicate life.
One thing that just now occurred to me is that as long as we maintain
the c
>
>
> BTW, does anyone have an opinion about changing the upper limit for
> default_stats_target to, say, 1? These tests suggest that you
> wouldn't want such a value for a column used as a join key, but
> I can see a possible argument for high values in text search and
> similar applications.
Tom Lane wrote:
> Bruce Momjian writes:
> > Let me outline the simplest API, assuming we are using table-level
> > granularity for the security columns.
> > CREATE TABLE would support
> > WITH (ROWACL = TRUE/FALSE);
> > for row-level acl and:
> > WITH (SECEXT = TRUE/FALSE);
> > for SE-Linu
Peter Eisentraut writes:
> On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
>>> How can we stick all of these in the same column at the same time?
>>
>> Why would we want to?
> Because we want to use SQL-based row access control and SELinux-based row
> access control at the same time. Isn
"Robert Haas" writes:
> Ah, that makes sense. Here's a test case based on Greg's. This is
> definitely more than linear once you get above about n = 80, but it's
> not quadratic either. n = 1000 is only 43x n = 80, and while that's
> surely more than 1000/80 = 12.5, it's also a lot less than (1
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
> > How can we stick all of these in the same column at the same time?
>
> Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same time. Isn't this exactly one of the objectio
On Thu, Dec 11, 2008 at 4:29 PM, Tom Lane wrote:
> Greg Stark writes:
>>> A variable prefetch_pages is defined as "unsigned" or "int"
>>> in some places. Why don't you define it only once in a header
>>> and include the header in source files?
>
>> Just... Which header?
>
> MHO: the header that g
Peter Eisentraut wrote:
> On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
> > The idea is that the security columns will hold an OID and the OID will
> > point to a row in a table that contains the security rights/ACL for the
> > column, with multiple rows using the same rights OID.
>
>
2008/12/11 Peter Eisentraut <[EMAIL PROTECTED]>:
> On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote:
>> maybe this combination should be safe
>>
>> $name => or $name -> ...
>>
>> it's not used everywhere
>
> Why don't you actually just implement the whole thing first using a random,
>
Peter Eisentraut wrote:
> About the error message, I find neither version to be very good. People see
> these messages and don't know what to do.
I agree. People see this:
ERROR: cache lookup failure for constraint 123123123
and they think it means the same as this:
ERROR: cache lookup fail
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
> Peter Eisentraut wrote:
> > On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
> >> I think there should be only *one* underlying column and that it should
> >> be manipulable by either SQL commands or selinux. Otherwise you're
> >> ma
On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote:
> maybe this combination should be safe
>
> $name => or $name -> ...
>
> it's not used everywhere
Why don't you actually just implement the whole thing first using a random,
simple, and nonconflicting syntax?
Adjusting the syntax to
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
>> I think there should be only *one* underlying column and that it should
>> be manipulable by either SQL commands or selinux. Â Otherwise you're
>> making a lie of the primary argument for having
Greg Stark <[EMAIL PROTECTED]> writes:
>> A variable prefetch_pages is defined as "unsigned" or "int"
>> in some places. Why don't you define it only once in a header
>> and include the header in source files?
> Just... Which header?
MHO: the header that goes with the source file that is most con
On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
> The idea is that the security columns will hold an OID and the OID will
> point to a row in a table that contains the security rights/ACL for the
> column, with multiple rows using the same rights OID.
That sounds somewhat scary for a nu
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise you're
making a lie of the primary argument for having the SQL feature at all.
Well
2008/12/11 Hannu Krosing <[EMAIL PROTECTED]>:
> On Thu, 2008-12-11 at 16:48 +0100, Pavel Stehule wrote:
>> 2008/12/11 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Thu, 2008-12-11 at 15:20 +0200, Dmitry Turin wrote:
>> >> Hi, Pavel.
>> >>
>> >> > you have to show some real product, real project
>> >>
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
> I think there should be only *one* underlying column and that it should
> be manipulable by either SQL commands or selinux. Otherwise you're
> making a lie of the primary argument for having the SQL feature at all.
Well, an SQL-manipulated r
> I think there should be only *one* underlying column and that it should
> be manipulable by either SQL commands or selinux. Otherwise you're
> making a lie of the primary argument for having the SQL feature at all.
I agree that we're getting pretty far afield from the original
proposal, but I d
On Thu, 2008-12-11 at 16:48 +0100, Pavel Stehule wrote:
> 2008/12/11 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Thu, 2008-12-11 at 15:20 +0200, Dmitry Turin wrote:
> >> Hi, Pavel.
> >>
> >> > you have to show some real product, real project
> >>
> >> Money will not be confirmed, until size of it wil
On Thu, Dec 11, 2008 at 8:09 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
>
>
> I'm not sure if we should set the bits in very aggressively. If we're more
> aggressive about setting the bits, it also means that we have to clear the
> bits more often, increasing the likelihood of contention tha
On Thursday 11 December 2008 17:43:38 KaiGai Kohei wrote:
> In addition, I want folks to remind that the Row-level ACLs are not
> designed based on SQL standards. Thus, I called it one of the enhanced
> securities.
We have a lot of things in our code that are nonstandard, beyond the standard,
enh
Bruce Momjian wrote:
At this point I am so confused I don't have any response.
Are you discussing the case when we start a PostgreSQL with $PGDATA
generated by different binary?
At first, please consider the case when we start SE-PostgreSQL with
$PGDATA generated by vanilla binary.
(1) In this
1 - 100 of 169 matches
Mail list logo
