On Thu, 4 Nov 2004, Neil Conway wrote:
> On Wed, 2004-11-03 at 14:45, Neil Conway wrote:
> > Attached is a patch that makes some improvements to the contrib/ build.
>
This breaks make install for the mysql module with
/bin/sh ../../config/install-sh -c -m 644 ./README.mysql
/home/jurka/tmp/p
On Thu, 2004-11-04 at 19:23, Kris Jurka wrote:
> This breaks make install for the mysql module [...]
Sorry. I could have sworn I tested this, but obviously I neglected to.
Fixed, thanks for the report.
-Neil
---(end of broadcast)---
TIP 3: if po
Tom Lane wrote:
> If we are going in that direction, all the files installed by this
> subdirectory should be suppressed (ie, findoidjoins and
> README.findoidjoins too).
Why not move it to src/tools, so no one gets the impression that it is
user code?
--
Peter Eisentraut
http://developer.postg
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Why not move it to src/tools, so no one gets the impression that it is
> user code?
I thought about that earlier, but concluded it wasn't worth the loss of
CVS history.
regards, tom lane
---(end of br
Minor re-wording following recent locking changes.
--
Best Regards, Simon Riggs
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/reindex.sgml,v
retrieving revision 1.24
diff -d -c -r1.24 reindex.sgml
*** reindex.sgml 24 Oct 200
I enclose a doc patch for the effective_cache_size parameter in
runtime.sgml: efcdoc.patch
Also, another minor patch which prevents effective_cache_size and
random_page_cost from being set incorrectly: plancost.patch
- previously it was possible to set effective_cache_size to 0, which
would then b
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Why not move it to src/tools, so no one gets the impression that it is
> > user code?
>
> I thought about that earlier, but concluded it wasn't worth the loss of
> CVS history.
I have cou
On Thu, 2004-11-04 at 16:37, Simon Riggs wrote:
> Also, another minor patch which prevents effective_cache_size and
> random_page_cost from being set incorrectly: plancost.patch
> - previously it was possible to set effective_cache_size to 0, which
> would then be ignored and treated as 1 at run-ti
Simon Riggs <[EMAIL PROTECTED]> writes:
> Minor re-wording following recent locking changes.
Applied with minor editorialization.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the u
Simon Riggs <[EMAIL PROTECTED]> writes:
> I enclose a doc patch for the effective_cache_size parameter in
> runtime.sgml: efcdoc.patch
Applied after translation into English ;-)
> Also, another minor patch which prevents effective_cache_size and
> random_page_cost from being set incorrectly: plan
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Can this be discussed for 8.1?
It's been discussed, and rejected, several times already. There aren't
any alternatives that are enough better than CVS to be worth the
changeover effort.
regards, tom lane
--
On Thu, 4 Nov 2004, Alvaro Herrera wrote:
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Why not move it to src/tools, so no one gets the impression that it is
user code?
I thought about that earlier, but concluded it wasn't worth the loss of
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> why would we lose CVS history? I can physically move the files in
> /cvsroot to accomplish this ... just tell me what needs to move, and to
> where ...
If you physically move the files, that would retroactively change their
placement in back vers
On Thu, 4 Nov 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
why would we lose CVS history? I can physically move the files in
/cvsroot to accomplish this ... just tell me what needs to move, and to
where ...
If you physically move the files, that would retroactively change t
On Thu, 2004-11-04 at 19:13, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I enclose a doc patch for the effective_cache_size parameter in
> > runtime.sgml: efcdoc.patch
>
> Applied after translation into English ;-)
>
Yes, the most significant bit often seems to get flipped in e
Tom Lane wrote:
AFAICS the only nondestructive way to do this is to cvs delete and cvs
add, with a commit comment saying where the files were moved from. Then
when you are looking at them in CVS, you'd have to navigate over to the
previous location (by hand, probably; the commit comment isn't goin
Tom,
(I'm rather interested to know whether any other SCMs have a better
solution to this problem, and if so what it is. It's not obvious how
to do better.)
I've been working with a few SCM's and IMHO only one of them really
handles this really well. That's ClearCase. I'm well aware that
ClearCa
On Fri, 5 Nov 2004 07:02 am, Marc G. Fournier wrote:
> On Thu, 4 Nov 2004, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> why would we lose CVS history? I can physically move the files in
> >> /cvsroot to accomplish this ... just tell me what needs to move, and to
> >>
Hi,
On Thursday 04 November 2004 20:41, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > why would we lose CVS history? I can physically move the files in
> > /cvsroot to accomplish this ... just tell me what needs to move, and to
> > where ...
>
> If you physically move the f
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
>>Can this be discussed for 8.1?
>
>
> It's been discussed, and rejected, several times already. There aren't
> any alternatives that are enough better than CVS to be worth the
> changeover effort.
The effort is not so big: http://cvs
OK, it turns out there were multiple problems with psql \e and \!
related to quoting and the use of Win32 API functions. That attached
patch fixes both of these, and uses stat() under Win32, but not
WIN32_CLIENT_ONLY.
---
W
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Tom Lane)
transmitted:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Can this be discussed for 8.1?
>
> It's been discussed, and rejected, several times already. There
> aren't any alternatives that are enough better than
[ Oleg, I've CC'd you because this patch makes some modifications,
albeit trivial ones, to tsearch2; let me know if you object to me
applying it ]
This patch makes some cleanups to contrib/ to silence some sparse
warnings:
- remove pointless "extern" keyword from some function definitions in
cont
Attached is a patch that makes some cleanups and improvements to GiST,
as well as a few semi-related cleanups. Changes:
- previously, GiST did not make any use of the backend's memory context
infrastructure. This made implementing indexes using GiST unnecessarily
difficult and fragile: if your imp
24 matches
Mail list logo
