Greg Stark writes:
> On 26 May 2009, at 19:58, Tom Lane wrote:
>> http://archives.postgresql.org/pgsql-hackers/2007-10/msg01243.php
> Uhm the rap you quoted was ambiguous but I read it as referring to the
> ability I described if viewing the difference between two patches --
> which I didn't
Uhm the rap you quoted was ambiguous but I read it as referring to the
ability I described if viewing the difference between two patches --
which I didn't name but is in fact interdiff.
--
Greg
On 26 May 2009, at 19:58, Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane escribió:
IIRC i
Alvaro Herrera writes:
> Tom Lane escribió:
>> IIRC it was demonstrated to be broken the last time it was proposed
>> as a solution to our problems. Maybe it's been fixed since then, but
>> I don't have any confidence in it, since evidently it's not been stress
>> tested very hard.
> I think you
Tom Lane escribió:
> Robert Haas writes:
> > On Tue, May 26, 2009 at 10:09 AM, Tom Lane wrote:
> >> I don't trust filterdiff one bit :-(
>
> > For any particular reason, or just natural skepticism?
>
> IIRC it was demonstrated to be broken the last time it was proposed
> as a solution to our pr
Robert Haas writes:
> On Tue, May 26, 2009 at 10:09 AM, Tom Lane wrote:
>> I don't trust filterdiff one bit :-(
> For any particular reason, or just natural skepticism?
IIRC it was demonstrated to be broken the last time it was proposed
as a solution to our problems. Maybe it's been fixed sinc
On Tue, May 26, 2009 at 10:09 AM, Tom Lane wrote:
> Greg Stark writes:
>> I'll repeat my suggestion that everyone poo-pooed: we can have the
>> mail list filters recognize patches, run filterdiff on them with our
>> prefered options, and attach the result as an additional attachment
>> (or link t
Greg Stark writes:
> I'll repeat my suggestion that everyone poo-pooed: we can have the
> mail list filters recognize patches, run filterdiff on them with our
> prefered options, and attach the result as an additional attachment
> (or link to some web directory).
The argument that was made
Tom Lane píše v po 25. 05. 2009 v 13:07 -0400:
> Zdenek Kotala writes:
> > Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
> >> In any case, the barriers to implementing 8.3-style hash indexes in 8.4
> >> are pretty huge: you'd need to duplicate not only the hash AM code, but
> >> also all the has
I'll repeat my suggestion that everyone poo-pooed: we can have the
mail list filters recognize patches, run filterdiff on them with our
prefered options, and attach the result as an additional attachment
(or link to some web directory).
I think it would be simple to do and would be happy to
Hi,
On 05/26/2009 01:39 PM, Peter Eisentraut wrote:
On Monday 25 May 2009 20:58:59 Andres Freund wrote:
and executing
`git config --global diff.context.command "git-external-diff"`
We already knew that you could do it with a wrapper. But that isn't the
answer we were looking for, because it w
On Monday 25 May 2009 20:58:59 Andres Freund wrote:
> and executing
> `git config --global diff.context.command "git-external-diff"`
We already knew that you could do it with a wrapper. But that isn't the
answer we were looking for, because it will basically mean that 98% of casual
contributors
On 05/25/2009 07:58 PM, Andres Freund wrote:
On 05/25/2009 07:53 PM, Andres Freund wrote:
On 05/25/2009 07:31 PM, Tom Lane wrote:
David Fetter writes:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how about
pestering git
Andres Freund writes:
>> You can define that a subset (or all) files use a specific "diff driver"
>> in the repository - unfortunately the definition of that driver has to
>> be done locally. Defining it currently involves installing a wrapper
>> like the one on http://wiki.postgresql.org/wiki/Tal
On 05/25/2009 07:53 PM, Andres Freund wrote:
On 05/25/2009 07:31 PM, Tom Lane wrote:
David Fetter writes:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how about
pestering git upstream to support diff -c output format?
I
On 05/25/2009 07:31 PM, Tom Lane wrote:
David Fetter writes:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how about
pestering git upstream to support diff -c output format?
It looks like this is doable with a suitable g
On 05/25/2009 07:20 PM, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how about
pestering git upstream to support diff -c output format?
It looks like this is doable with a suitabl
David Fetter writes:
> On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
>> If you'd like to accomplish something *useful* about this, how about
>> pestering git upstream to support diff -c output format?
> It looks like this is doable with a suitable git configuration file
> such as $HOM
David Fetter wrote:
> On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
> > If you'd like to accomplish something *useful* about this, how about
> > pestering git upstream to support diff -c output format?
>
> It looks like this is doable with a suitable git configuration file
> such as $H
Zdenek Kotala writes:
> Tom Lane pÃÅ¡e v ne 24. 05. 2009 v 18:46 -0400:
>> In any case, the barriers to implementing 8.3-style hash indexes in 8.4
>> are pretty huge: you'd need to duplicate not only the hash AM code, but
>> also all the hash functions, and therefore all of the hash pg_amop and
>
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
> If you'd like to accomplish something *useful* about this, how about
> pestering git upstream to support diff -c output format?
It looks like this is doable with a suitable git configuration file
such as $HOME/.gitconfig or (finer grain)
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, May 25, 2009 at 11:45:33AM -0400, Stephen Frost wrote:
> >> I'm all for moving to git, but not until at least the core folks are
> >> more familiar with it and have been using it.
>
> > Which ones aren't
David Fetter writes:
> On Mon, May 25, 2009 at 11:45:33AM -0400, Stephen Frost wrote:
>> I'm all for moving to git, but not until at least the core folks are
>> more familiar with it and have been using it.
> Which ones aren't familiar and haven't been using it for at least the
> past year? I co
David Fetter wrote:
On Mon, May 25, 2009 at 09:59:14AM -0400, Tom Lane wrote:
Dimitri Fontaine writes:
Tom Lane writes:
The rearrangement might be marginally nicer from a code
beautification point of view --- right now we're a bit
inconsistent about whether datatype-specific
On Mon, May 25, 2009 at 11:45:33AM -0400, Stephen Frost wrote:
> David,
>
> * David Fetter (da...@fetter.org) wrote:
> > It's pretty relevant as far as the schedule goes. I'm not alone
> > thinking that the appropriate place to make this change, given
> > buildfarm support, is at the transition t
David,
* David Fetter (da...@fetter.org) wrote:
> It's pretty relevant as far as the schedule goes. I'm not alone
> thinking that the appropriate place to make this change, given
> buildfarm support, is at the transition to 8.5.
>
> CVS is dead. Long live git! :)
I'm all for moving to git, but
Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
> Kenneth Marshall writes:
> > On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote:
> >>> Attached patch cleanups hash index headers to allow compile hasham for
> >>> 8.3 version. It helps to improve pg_migrator with capability to migrate
>
On Mon, May 25, 2009 at 09:59:14AM -0400, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Tom Lane writes:
> >> The rearrangement might be marginally nicer from a code
> >> beautification point of view --- right now we're a bit
> >> inconsistent about whether datatype-specific hash functions live
Dimitri Fontaine writes:
> Tom Lane writes:
>> The rearrangement might be marginally nicer from a code beautification
>> point of view --- right now we're a bit inconsistent about whether
>> datatype-specific hash functions live in hashfunc.c or in the datatype's
>> utils/adt/ file. But I'm not
Hi,
Tom Lane writes:
> The rearrangement might be marginally nicer from a code beautification
> point of view --- right now we're a bit inconsistent about whether
> datatype-specific hash functions live in hashfunc.c or in the datatype's
> utils/adt/ file. But I'm not sure that removing hashfunc
Kenneth Marshall writes:
> On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote:
>>> Attached patch cleanups hash index headers to allow compile hasham for
>>> 8.3 version. It helps to improve pg_migrator with capability to migrate
>>> database with hash index without reindexing.
> How d
On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote:
> I forgot to fix contrib. Updated patch attached.
>
> Zdenek
>
> Zdenek Kotala pe v p?? 22. 05. 2009 v 16:23 -0400:
> > Attached patch cleanups hash index headers to allow compile hasham for
> > 8.3 version. It help
I forgot to fix contrib. Updated patch attached.
Zdenek
Zdenek Kotala píše v pá 22. 05. 2009 v 16:23 -0400:
> Attached patch cleanups hash index headers to allow compile hasham for
> 8.3 version. It helps to improve pg_migrator with capability to migrate
> database with hash index
Attached patch cleanups hash index headers to allow compile hasham for
8.3 version. It helps to improve pg_migrator with capability to migrate
database with hash index without reindexing.
I discussed this patch year ago with Alvaro when we tried to cleanup
include bloating problem. It should reduc
33 matches
Mail list logo
