I was kind of afraid of that. So, how could one implement such a function
set?
Write a function (say, score_contains) that returns NULL whenever
contains would return false, and the score otherwise.
SELECT * FROM (
SELECT *, score_contains(mytable.title, 'Winding Road', 1) AS
score FROM
That way, instead of just an appeal to the masses to volunteer for
$NEBULOUS_TASK, we can say something like Please volunteer to review
patches. Doing an initial patch review is easy, please see our guide
link to learn more.
+1. I'll review a patch if you like, but the patch I have in this
Updated patch attached, based on comments from Ryan Bradetich and Tom
Lane, and sync'd to latest CVS version.
...Robert
On Mon, Sep 1, 2008 at 9:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
On Mon, Sep 1, 2008 at 1:00 PM, Tom Lane [EMAIL PROTECTED] wrote:
Maybe we want a new function has_sequence_privilege() instead?
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Applied with really pretty minor revisions --- this was a nice clean
patch. Changes I can recall making:
Woo-hoo, my first patch. Thanks for the cleanup.
...Robert
* You missed one or two documentation references to DELETE privilege.
* You modified the privileges test to create another
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
0.233165248762816
0.62126633618027
(2 rows)
The standard specifies that non-recursive WITH should be evaluated
once.
What
3. I think this is a must fix because of the point about volatile
functions --- changing it later will result in user-visible semantics
changes, so we have to get it right the first time.
I don't entirely agree with #3. It is user-visible, but only in the
sense that someone is depending on
My interpretation of 7.13: General Rules: 2.b is that it should be
single evaluation, even if RECURSIVE is present.
The previous discussion was here:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01292.php
I am blind, I didn't find any reason, why materialisation isn't
This would have definitional problems of its own, however. If you interpret
K, M, and G strictly as unit-less multipliers, then
SET shared_buffers = 2 G
I don't think it would be a good idea to make them unit-less, for
exactly the reasons you mention.
We could possibly settle some of these
There isn't sufficient support for such a feature.
It sounds like a useful feature to me.
In any case, why
would creation time (as opposed to any other time, eg last schema
modification, last data modification, yadda yadda) be especially
significant?
Those would be nice to have too, but
A good start might be to always OUTPUT memory parameters using the
same base unit.
SHOW gives output that matches what you input.
Not for me it doesn't.
portal=# show temp_buffers;
temp_buffers
--
1024
(1 row)
portal=# set temp_buffers = '16MB';
SET
portal=# show temp_buffers;
When people aren't keeping track of their DDL, that is very strictly a
process problem on their end. When people are shooting themselves in
the foot, it's a great disservice to market Kevlar shoes to them.
I can't believe anyone is going to stop tracking their DDL because,
ooh goody, now we
I'm not planner guru but it seems to me that BETWEEN clause could be
rewritten as a IN clause for integer data types and small interval.
Where should the line be drawn.
Define small :)
When the estimated cost is lower?
...Robert
--
Sent via pgsql-hackers mailing list
a) Verbosely spelling out the units in the default config file
temp_buffers = 16 megabytes
or
temp_buffers = 16 milliblocks :-)
Naive users who favor cutpaste will use the verbose words
that should leave little room for confusion. Power-users
who know the short forms from the
I meant that -- hypothetically if we did accept the feature as-is -- the
number of evaluations would be documented to be undefined, not N. That
would avoid the backwards-compatibility problem.
This one point is probably not worth discussing now, because argument
#1 and #2 stand on their own.
temp_buffers is actually special-cased in the code because
/*
* We show the GUC var until local buffers have been initialized, and
* NLocBuffer afterwards.
*/
It is not clear to me right now why that is a good idea. But it is only
this one paramter.
OK, well that's not so bad
I'd imagine that even if applying the WAL on the slave is blocked, it's
still streamed from the master to the slave, and in case of failover the
slave will fast-forward before starting up as the new master. Of course, if
it has fallen 3 days behind because of a giant reporting query, it can
Disabling autovacuum can have catastrophic effects, since it disables
the ANALYZing of tables.
Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
ANALYZE times are fairly bounded because of the way we do sampling.
VACUUM times are not bounded at all, and typically O(n).
Please provide some specifics. It's been a very long time since the
planner was completely unaware of the size of such a table. Lack of
stats is certainly a handicap, but I'm not convinced it should result
in horrible plans. Maybe a more appropriate answer to this type of
issue is to tweak
I am not sure, if these rule is good. Somebody who develop on
postgresql should have a problems when they will be port to other
databases in future. Reserved words in standards should be respected.
I disagree. I have never ported an app written for PostgreSQL to
another database system, and
I tend to agree with Alvaro that there's not very much of a use case for
an analyze-only autovacuum mode. Assuming that we get to the point of
having a parallelizing pg_restore, it would be interesting to give it an
option to include ANALYZE for each table it's loaded among the tasks
that it
[2] Make a new implementation of OS-independent fine grained access control
If it is really really necessary, I may try to implement a new separated
fine-grained access control mechanism due to the CommitFest:Nov.
However, we don't have enough days to develop one more new feature from
the
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different security mechanisms
have to have same
C isn't going anywhere anytime soon. Look at its history, it has survived
its 'replacements' over and over again. The most popular kernels, shells
and applications are all still written in C (new and old). Where are the
warning signs that it is dwindling?
To add to this:
It's easy to
Well, does it make sense to add column-level privileges just for
SE-Linux?
That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?
Er, Bruce was asking about
Yeah, that's what I keep hearing that the spooks think they want.
I can't imagine how it would play nice with SQL-standard integrity
constraints. Data that apparently violates a foreign-key constraint,
for example, would give someone a pretty good clue that there's
something there he's not
The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not unreasonable to discuss
just how large that set might be while we debate whether to accept the
patch.
Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.
In addition, these are invoked via security hooks which are declared
as inline functions. So, I think it does not give us additional loss of
performances when you don't add the compile time option explicitly.
That is
Are you saying the performance penalty when full functionalities are
enabled?
(The meaning of bells and whistles is unclear for me.)
Yes, that's what I meant. (Sorry.)
We can show it on the page.22 of my presentation in PGcon2008.
This is just a different syntax for KaiGai's label storage
implementation. It doesn't really answer any of the hard questions,
like what the heck is the behavior of foreign keys.
What do you find inadequate about KaiGai's answers to those hard questions?
...Robert
--
Sent via pgsql-hackers
Here is how I think SQL-level row permissions would work:
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called security_context which would store the
oid of the role that
I like the idea of a WITH ROW SECURITY option to enable row-level
security - that way, tables that don't need it don't have to pay for
it, but I like the idea of storing a full ACL, as KaiGai proposed,
rather than just a single role. Seems much more powerful.
... and even more ill-defined.
You mean her data just disappears? Doesn't sound very reasonable to me.
In reference cases, we can consider she looks the tables via something
like VIEWs implicitly. The VIEW can hide several tuple, but it does
not break any reference consistency in the raw level.
I don't understand what
I think you have to resign yourself to the fact that a user who can
see only a subset of the rows in a table may very well see apparent
foreign-key violations. But so what?
So you're leaking information about the rows that they're not supposed
to be able to see. This is not what I would
The literature pointers that Andrew just gave us seem promising to me.
Who's going to go searching for some useful info?
I couldn't find much on the pages linked directly from the link Andrew
sent, but a Google search for site:ieee-security.org database turned
up the following:
I'm just getting back around to this now. I guess I'm wondering if
someone could advise me on the best way of getting closer to a
committable patch.
The original patch just allows additional columns to be appended to
the previous column list (while disallowing all other sorts of
changes,
Agreed. It's already horrible that we suggest people use OFFSET 0, only
because we don't want to define formal optimizer hints (and that's *exactly*
what OFFSET 0 is).
Yes, especially since TFM says:
OFFSET 0 is the same as omitting the OFFSET clause.
Unless I'm looking at the wrong part of
If the planner chooses to do this as a nestloop with table2 on the
inside, then expensive_function() can get evaluated multiple times on
the same row of table2. We really don't make very many guarantees about
what will happen with functions inside inlined views, even with offset
0 as an
3. The patch introduces a slight weirdness: if you create two FKs on the
same column at the same time you end up with two constraints with
identical names. Drop constraint then removes them both, though in other
respects they are both valid, just not uniquely. CREATE INDEX avoids
this by way
I'm just grumpy because I can't see a way to do the
patch-on-patch-on-patch that I'll need to make this all work for Nov 1.
So big patch here we come. But that's just the way it is and I'll stop
honking about it.
This is one of the problems that DVCSs are supposed to solve ... have
you
Urk... this seems pretty undesirable.
OK, but please say what behaviour you would like in its place.
Or are you saying you dislike this so much that you would prefer not to
be able to run ALTER TABLE concurrently?
Personally, yes. I work mostly with small databases where ease of
management
This is not a support list. Sounds like you should consider
purchasing a commercial support contract, or you could try asking on
pgsql-general.
...Robert
On Tue, Oct 7, 2008 at 4:30 PM, Grzegorz Jaskiewicz [EMAIL PROTECTED] wrote:
On 2008-10-06, at 20:59, Grzegorz Jaskiewicz wrote:
Hey
Can you *do* the row-level permission?
I don't think there's any consensus on a design.
Getting consensus on a design seems to actually be one of the harder
aspects of PostgreSQL development. The pattern seems to be:
1. Someone submits a patch. By definition, the patch embodies some
I get the same thing on 8.2.9.
...Robert
On Wed, Oct 8, 2008 at 2:29 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=# create or replace function foo ()
The attached patch allows uuid_in() to parse a wider variety of
variant input formats for the UUID data type, per the TODO named in
the subject line.
Original discussion here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01214.php
1) Reduced error checking.
2) The '-' is not the only character that people have used. ClearCase uses
'.' and ':' as punctuation.
3) People already have the option of translating the UUID from their
application to a standard format.
4) As you find below, and is probably possible to
Anyways - I only somewhat disagree. I remember the original discussions, and
I remember agreeing with the points to keep PostgreSQL UUID support thin and
rigid. It's valuable for it to be built-in to the database. It's not
necessarily valuable for PostgreSQL to support every UUID version or
3) People already have the option of translating the UUID from their
application to a standard format.
Regexp, the swiss-army knife of data manipulation. ;)
While possible, it really is not that easy and efficient. At least we should
accept dashless UUIDs, so instead of tediously
that only depends on definition of 'common variant'. Will it be just code
that will accept letters and digits, and trying to make that into UUID ?
You are attacking a straw man. No one is proposing that.
I think those who designed their code to produce or accept non standard
UUID, should
Is it problem do for non standard UUID formats pgfoundry project?
I'm not volunteering set up a pgfoundry project to maintain something
that can be accomplished with a patch that adds 19 lines of new code
(and removes 9). This functionality is useful in core because it will
Just Work. If you
On Fri, Oct 10, 2008 at 3:48 PM, Grzegorz Jaskiewicz
[EMAIL PROTECTED] wrote:
I think it will be as expensive to app to convert UUID to standard format,
as it would be too postgrsql.
But if psql does it - everyone would expect it to do it right. You can't
possibly detect all forms of screwed
I dislike all own creatures - because nobody will understand so do
some wrong thing - using non standard formats is bad thing. So it's is
necessary, then who need it then he found it on pgfoundry. But why
smudge core?
I'm opposed to smudging core, but I'm in favor of this patch. :-)
Of
intagg: the aggregation function has been obsolete since 7.4 because
standard array functionality supports the same. intagg has a nice
equivalent for UNROLL, but it only works for arrays of INT, and only
one-dimensional arrays. Has not been updated since 2001.
I think this one can be
After reading Josh Berkus's email suggesting that the intagg module be
dropped, I was wondering what would be required to create a array
enumerator (variously called unnest, unroll, array_enum, and, as
contemplated by the TODO list, array_to_set). Pavel Stehule's
generate_subscripts function
CREATE AGGREGATE array_accum (anyelement)
CREATE OR REPLACE FUNCTION array_enum(anyarray)
Have you actually tried these functions on large data sets?
No. :-)
They're not in the same performance league as intagg. Your array_accum is
O(n^2)!
It's not mine - I copied it from the official
If it's a bad way to do it, that's certainly an argument for keeping
(or maybe generalizing) intagg.
There was actually a patch this past commitfest to *add* functionality to
intagg. When I reviewed it I said it would make more sense to generalize it
and integrate that functionality into the
it), please implement
UNNEST operator.
Regards
Pavel Stehule
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0710arocena/index.html
2008/10/11 Robert Haas [EMAIL PROTECTED]:
After reading Josh Berkus's email suggesting that the intagg module be
dropped, I was wondering what would
On Sat, Oct 11, 2008 at 7:53 AM, Robert Haas [EMAIL PROTECTED] wrote:
There's nothing in that functionality that contemplates
multi-dimensional arrays. Since we have multi-dimensional arrays,
oughtn't we provide the basic functions to deal with them?
array_ndims has got to be at least as useful
If we were to flatten it to a plain select * from z then maybe things
would work all right, but the present implementation treats both WITH
clauses as equally requiring single evaluation.
Surely it should be a single evaluation for each time that branch of
the upper WITH is recursively
I wonder if this could be implemented using the window-function
infrastructure...
...Robert
On Sun, Oct 12, 2008 at 9:07 AM, Grzegorz Jaskiewicz
[EMAIL PROTECTED] wrote:
that's a shame.
I figure, with the WITH ... AS .. you can kind of speed up counts, just by
doing it once - now. But still,
I'm not so sure that non-console terminal service sessions should be
categorized as pretty rare.
I use them routinely.
For installing and running Postgres? Note that we're not talking about
running clients apps here, but the server itself.
Sure, why not? I mean, I've come across
There must be a way to get string_to_array() to evaluate only once, yes?
WITH, but that's not going to help you for backward compatibility.
If you used plpgsql you could assign the string_to_array result to a
variable and then work off the variable, but I'm not sure that's
really better.
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
telling people they must have. My view is that we revert the change
(well, replace it with something that looks less like a broken attempt
to use the global namespace) and
Obviously that wasn't the intent of the above, but I guess it is the net
effect. Either way, I don't think it's a huge problem, it just means that
PG may not be able to restart for a few seconds until the OS has time to
clean-up the locks.
Seconds?
Try log off and log on again, and if that
On Wed, Oct 15, 2008 at 11:29 AM, Tom Lane [EMAIL PROTECTED] wrote:
Decibel! [EMAIL PROTECTED] writes:
Since this is something that's not supposed to happen, making it a
WARNING might be appropriate too...
Uh, the complaint was that the message is too noisy, not that it isn't
noisy enough.
I've been taking a look at this as well and came up with a slightly
different approach. The attached patch is intended to go in core (not
contrib) and uses some array-construction facilities that already
exist in core. I'm not sure which approach is better, so I'll throw
this out there with
I think the real question is: what other kinds of correlation might
people be interested in representing?
Yes, or to phrase that another way: What kinds of queries are being
poorly optimized now and why?
I suspect that a lot of the correlations people care about are
extreme. For example, it's
* pg_last_recovered_xact_xid()
Will throw an ERROR if *not* executed in recovery mode.
returns bigint
* pg_last_completed_xact_xid()
Will throw an ERROR *if* executed in recovery mode.
returns bigint
Should these return xid?
...Robert
--
Sent via pgsql-hackers mailing list
How can you make that the default? Won't it immediately break every
installation without certificates?
*all* SSL installations have certificate on the server side. You cannot
run without it.
s/without certificates/with self-signed certificates/
which I would guess to be a common
Seems like we ought to clean this up. I'm not sure which way to jump
though: should we decree that arrays of no elements must always have
zero dimensions, or should we get rid of that and standardize on, say,
1-D array with lower bound 1 and upper bound 0?
Isn't the zero-dimensional array
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Can we call the function minimal_update_trigger, rather than min_...
Minimal really fails to convey the point here IMHO. How about
something like suppress_no_op_updates_trigger?
+1.
How about one of these?:
suppress_same_value_updates_trigger
suppress_no_change_updates_trigger
suppress_no_effect_updates_trigger
I like the first one. A trigger firing would be an effect, and
possibly a change, but same value seems very clear.
...Robert
--
Sent via pgsql-hackers
I think you're asking for more scriptability in psql. Personally I
think that would be a great idea, but we need a lot more than what's
being proposed here. We'll also need loops, conditionals, etc. We've
had patches for those submitted over the years, but one at a time they
are easily
True enough, but a car doesn't roll without at least four wheels.
True, but I'm not sure why we'd need three other wheels to make this
feature roll, or what those three wheels would be. Personally, I
would never write a complicated script in psql rather than perl, but I
can imagine using this
So now that we have both agreed with each other, what do we do? :P
Well, the original suggestion was to add it to the TODO list. That
seems reasonable to me.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
There's 6 cases here, in a 2x3 array. In one dimension, the LHS can be
either a Var or a fixed value. In the other dimension, the three
possibilities are 1: everything on the RHS is a fixed value, 2: some fixed,
some not, 3: everything on the RHS is a variable:
[...lengthy discussion of
I really think we should have a way of telling if a array/row/record
variable is actually set to something, and I'm pretty sure that should be
unrelated to whether all the elements in it happen to be null.
+1. Also, can whatever syntax we introduce by something relatively
concise? Code that
I'm taking a look at doing the refactoring Tom Lane and Simon Riggs
discussed here:
http://archives.postgresql.org/pgsql-patches/2008-02/msg00155.php
In terms of the buffer manager, I think we can simply introduce a new
strategy type BAS_BULKWRITE and make it behave identically to
BAS_VACUUM.
Seems sane to me. I don't see the point of the HEAP_INSERT_BULK flag
bit --- providing or not providing bistate would cover that, and if
you have a bit as well then you have to define what the inconsistent
combinations mean. I concur with making all-zeroes be the typical
state of the flag
I thought that the bad case for a tuplestore was if the set returning
function was expensive and the user used it with a LIMIT clause. In the
tuplestore case you evaluate everything then throw it away.
I'm not terribly excited by that example --- but in any case, the real
solution to any
http://developer.postgresql.org/pgdocs/postgres/index.html
On Mon, Oct 27, 2008 at 12:11 PM, Webb Sprague [EMAIL PROTECTED] wrote:
Could I request that a link to the developer docs be posted along with
the release docs on
http://www.postgresql.org/docs/manuals/
?
First -- it is
they are already referenced in the development section of the website:
http://www.postgresql.org/developer/testing
I think - no. Mark this as dev-docu, but i think, this is a nice
feature.
+1
I think what we're talking about is adding a clearly-marked link to
the dev docs somewhere on
I always thought we considered that a bug though. It sure would be nice if we
could generate results as needed instead of having to generate them in
advance
and store all of them.
I suppose, but short of a fundamental rethink of how PL functions work
that's not going to happen. There's
I'm happy
to rip those changes back out and resubmit; they are a relatively
small proportion of the patch.
...Robert
On Sun, Oct 26, 2008 at 8:37 PM, Robert Haas [EMAIL PROTECTED] wrote:
Seems sane to me. I don't see the point of the HEAP_INSERT_BULK flag
bit --- providing or not providing
It's worth noting that this is the third version of this idea that has
been submitted. Ian Caulfield submitted a patch to add this, and so
did I. Someone should probably look at all three of them and compare.
...Robert
On Mon, Oct 27, 2008 at 1:41 PM, Jeff Davis [EMAIL PROTECTED] wrote:
On
So my idea would be to have the SQL function behavior choose to return values
either via tuplestore or via value-per-call, depending on the user
setting generator or lazy.
Done this way, the user could also choose for the function to be lazy or to
use a tuplestore whatever the language in
Buffer ReadBuffer(Relation reln, BlockNumber blockNum);
Buffer ReadBufferExt(Relation reln, ForkNumber forkNum, BlockNumber
blockNum, BufferAccessStrategy strategy, ReadBufferMode mode);
Buffer ReadBufferWithoutRelcache(RelFileNode rnode, bool isTemp, ForkNumber
forkNum, BlockNumber blockNum,
All of this is pie-in-the-sky for PL functions, and I think properly so:
the whole reason for supporting PLs is to enable doing things that SQL
does poorly or not at all. So expecting SQL to interoperate very
closely with them seems impossible, or at least unreasonably limiting.
The real
If you say its a loss you should publish timings to support that. Using
a BAS for VACUUM was a performance gain, not a loss.
Well, I can dig up and publish the timings from my laptop, but I'm not
sure where that will get us. Trust me, the numbers were higher with
BAS, otherwise I wouldn't be
I wonder if we should consider:
(1) moving all of the patches committed prior to 11/1 to a separate
section or page
(2) sorting the pending patches by complexity or subject matter
...Robert
On Wed, Oct 29, 2008 at 5:26 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Patch submitters,
Please make
(1) moving all of the patches committed prior to 11/1 to a separate
section or page
Why?
To reduce clutter, but I don't feel strongly about it.
(2) sorting the pending patches by complexity or subject matter
Sorting them by complexity would be great, if I thought I could do it. I'm
not
With session variables we could implement srf function in plpgsql like
current C srf function. Like
create or replace function foo()
returns record as $$
#option with_srf_context(datatype of srf context)
begin
return row(...);
end;
$$ language plpgsql;
Oh, sure - but what you can
The closing semicolon is strictly speaking not allowed here. We could
remove it, but that would probably upset pgindent?
I recall that we used to have a bunch of similar problems with the AIX
compilers a long time ago. Does anyone recall the solution, and do we still
care? (Note that it's
Ooooh yeah. Time for some caffeine.
...Robert
On Thu, Oct 30, 2008 at 9:34 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Robert Haas escribió:
The closing semicolon is strictly speaking not allowed here. We could
remove it, but that would probably upset pgindent?
I recall that we
You should try profiling the patch. You can count the invocations of the
buffer access routines to check its all working in the right ratios.
*goes and learns how to do profile PostgreSQL*
OK, that was a good suggestion. It looks like part of my problem here
is that I didn't put the CREATE
Whatever timings you have are worth publishing.
Here are the timings for copying the first ten million integers into a
one-column table created in the same transaction, with and without the
patch. As you can see, now that I've corrected my previous error of
not putting CREATE TABLE and COPY in
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
CREATE OR REPLACE FUNCTION show_qual()
RETURNS TEXT
LANGUAGE plperl
AS $$
return
Can you test whether using the buffer access strategy is a win or a
loss? Most of that gain is probably coming from the reduction in
pinning.
Patch resnapped to HEAD, with straightforward adjustments to
compensate for Heikki's changes to the ReadBuffer interface. See
attached.
New testing
Well done? It seems to me that we are right where we hoped not to be,
ie with a ton of barely-completed (if not self-admitted WIP) patches
dropped on us immediately before feature freeze. Today the commit fest
idea is looking like a failure.
If we actually manage to ship 8.4 within six
Without review, how can we determine the true state of a patch? I would
guess that you haven't done a review of all of them yourself to
determine that.
No, I'm talking about the comments that were made when submitting the
patch. A few people said things along the lines of this isn't really
1 - 100 of 21603 matches
Mail list logo
