Sven Suursoho wrote:
Hi,
Quoting Bruce Momjian [EMAIL PROTECTED]:
Great. Please supply documentation and it will be applied. Thanks.
Here it comes, including src+doc patches.
Updated sources according to Michael Fuhr's comments and fixed one FIXME.
Please check documentation
Tom, should I apply this patch now? Are you still considering other
options for this?
---
Bruce Momjian wrote:
Tom, I ran your tests with fsync off (as you did), and saw numbers
bouncing between 400-700 tps without my
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, should I apply this patch now? Are you still considering other
options for this?
Please wait. This issue is very far down the to-list in terms of size
or significance ... but I'll get to it.
regards, tom lane
Patch applied. Thanks.
I updated the README documentation for the new functions, attached. I
could not update the Japanese version of the README.
---
Satoshi Nagayasu wrote:
Bruce,
Attached patch has been cleaned
Uh, were are we in fixing/reviewing this?
---
Andrew Dunstan wrote:
I wrote:
Pavel Stehule wrote:
Hello,
I send two small patches. First does conversion from perl to
postgresql array in OUT parameters.
Where are we on the GUC comment/reload to defaults patch? Do we have
multiple people objecting to its application? Previously only Tom
objected, and Andrew partially.
---
Bruce Momjian wrote:
Tom Lane wrote:
Michael
Patch applied. Thanks.
I had to convert a lot of whitespace to tabs. It wasn't just the
whitespace, but whitespace that was 8 spaces. I assume you are reading
our code using an 8-space tab. Please see the developer's FAQ and try
to use tabs in future patches. Thanks.
Susanne Ebrecht wrote:
Is it too hard to rip it back out once the full row support
arrives? That seems speculation at best anyway.
That's what I was thinking. Glad someone else replied. ;-)
If you're looking for votes, +1. I'll gladly take a subset of the
Joe Conway wrote:
Sorry for the delay. I've done some rework to the original code sent by
Kai, mainly to reduce duplication with the existing synchronous case,
and to better fit with the existing docs, regression script, etc. I also
changed the return type of dblink_get_connections() to
Is this something people are interested in? I am thinking no based on
the lack of requests and the size of the patch.
---
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
stark wrote:
So I hacked
So the patch is being withdrawn by the author? OK.
---
Pavel Stehule wrote:
Hello,
This task can be better solved. There are some problems with strings, but
bigger problem is impossibility to pass nonscalar
Thanks. Yes, it is need for two reasons. In 8.2 you can set
standard_conforming_strings to on, meaning \' is really treated as \ and
', and because some encodings now can't support \' for security reasons,
though I don't think tsearch2 supports those multibyte encodings.
Anyway, applied to 8.2
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Victor B. Wagner wrote:
On 2006.08.30 at 10:14:02 -0400, Tom Lane wrote:
Victor B. Wagner [EMAIL PROTECTED]
On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the
bruce wrote:
I have merged your patch into current CVS and applied it; attached.
There was quite a bit of code drift. One drift area was the new
RETURNING clause; that was easy to fix. A more complex case is the
code no longer has values as ResTargets --- it is a simple a_expr list,
so I
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Log Message:
---
Change FETCH/MOVE to use int8.
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
Fixed with attached patch. The use case for this
I think it has to wait to 8.3. It's a complete mess that was submitted
unheralded at the last moment. Pavel needs to get into the habit of
submitting ideas first, not just patches. And there must be proper
documentation and working regression tests.
cheers
andrew
Bruce Momjian wrote:
Uh,
OK.
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Andrew Dunstan wrote:
I think it has to wait to 8.3. It's a complete mess that was submitted
unheralded at
Oh, let me add that this was first discussed on July 28:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01421.php
and a patch posted on July 30:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01559.php
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Victor B. Wagner wrote:
This patch adds following functionality to PostgreSQL
1. If PostgreSQL is compiled with
Peter Eisentraut wrote:
David Fetter wrote:
This patch clarifies the 'predicate locking' section in the docs.
What it does it raise the question what next-key locking is.
I don't think any of this matters for us. We should just remove the
part that claims that no other system
Like I said, at the last moment.
Bruce Momjian wrote:
Oh, let me add that this was first discussed on July 28:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01421.php
and a patch posted on July 30:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01559.php
Bruce Momjian [EMAIL PROTECTED] writes:
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
Fixed with attached patch. The use case for this was not FETCH, but
MOVE for 2gig tables.
There is *no* credible use case for this
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
Fixed with attached patch. The use case for this was not FETCH, but
MOVE for 2gig tables.
There is *no*
bruce wrote:
Patch applied. Thanks.
I had to convert a lot of whitespace to tabs. It wasn't just the
whitespace, but whitespace that was 8 spaces. I assume you are reading
our code using an 8-space tab. Please see the developer's FAQ and try
to use tabs in future patches. Thanks.
I
While this patch has new regression tests, it doesn't have new expected
output for it. Please update the patch to supply that. Thanks.
---
Pavel Stehule wrote:
Hello
This patch allows using any row expression in
Jim C. Nasby [EMAIL PROTECTED] writes:
On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote:
Whether a table is bootstrap or not doesn't seem useful to me.
Something that might be handy would be a method to determine if an
object is a system object or not (perhaps what the OP means
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, were are we in fixing/reviewing this?
It's dead for 8.2 --- Andrew's complaints are pretty serious at both
the conceptual and implementation levels, and there's been no sign of
discussion about how to fix them.
regards, tom
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for 2G tables).
Already done because of bad coding. You want the TODO item removed too?
As I said, I see no use case for it. Maybe if
29 matches
Mail list logo
