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.
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 l
"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
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 re
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. Thank
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.
>
>
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
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
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
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 wit
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
--
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
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,
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 fo
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,
> s
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 PROTECTE
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 dete
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
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 variab
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
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 text[],
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.
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.
---
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
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 p
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
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.
---
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
> Today on IRC David Fetter and some others were discussing version
> numbers and we realized that although libpq now provides the versi
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 m
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 docu
30 matches
Mail list logo
