On Thu, Nov 11, 2010 at 6:08 PM, Tom Lane wrote:
> Marti Raudsepp writes:
>> On Thu, Nov 11, 2010 at 17:24, Tom Lane wrote:
>>> Given that we have, in fact, never renamed any files in the history of
>>> the project, I'm wondering exactly why it thinks that the number of
>>> potential rename/copy
On 11/11/2010 10:17 AM, Aidan Van Dyk wrote:
We should adopt that philosophy. I suggest we limit all tables in future to
1m rows in the interests of speed.
As long as it's configurable, and if it would make operations on
smaller tables faster, than go for it.
And we should by defualt limit
Marti Raudsepp writes:
> On Thu, Nov 11, 2010 at 17:24, Tom Lane wrote:
>> Given that we have, in fact, never renamed any files in the history of
>> the project, I'm wondering exactly why it thinks that the number of
>> potential rename/copy targets isn't zero.
> Because git doesn't do "rename t
Aidan Van Dyk writes:
> Can you share what commit you were trying to cherry-pick, and what
> your resulting commit was? I can try and take a quick look at them
> and see if there is something obviously fishy with how git's trying to
> merge the new commit on the old tree...
See yesterday's line_
On Thu, Nov 11, 2010 at 17:24, Tom Lane wrote:
> Given that we have, in fact, never renamed any files in the history of
> the project, I'm wondering exactly why it thinks that the number of
> potential rename/copy targets isn't zero. The whole thing smells
> broken to me, which is why I am unhapp
Aidan Van Dyk writes:
>>> It's intentional behavior. It gives up when there are too many
>>> differences to avoid being slow.
> And, it's configurable, at least to diff and merge. If it's not
> available in all the other porcelains, yes, that would be bugs that
> should be fixed:
FWIW, I was s
On Thu, Nov 11, 2010 at 8:28 AM, Andrew Dunstan wrote:
>> It's intentional behavior. It gives up when there are too many
>> differences to avoid being slow.
And, it's configurable, at least to diff and merge. If it's not
available in all the other porcelains, yes, that would be bugs that
shoul
On 11/10/2010 07:51 PM, Robert Haas wrote:
(And no, don't you dare breathe a word about git making that
all automagically better. I have enough back-patching experience with
git by now to be unimpressed; in fact, I notice that its rename-tracking
feature falls over entirely when trying to ba
Robert Haas writes:
> work will help with that somewhat, but there's still that nasty
> business of needing to update shared_preload_libraries and bounce the
> server, at least for some modules.
We have 45 contribs (ls -l contrib | grep -c ^d), out of which:
auto_explain is shared_preload_libr
On Wed, Nov 10, 2010 at 7:01 PM, Andrew Dunstan wrote:
> The current name causes constant confusion. It's a significant misnomer, and
> leads people to distrust the code. There might be reasons not to change, but
> you should at least recognize why the suggestion is being made.
Is it your positio
On 11/10/2010 07:51 PM, Robert Haas wrote:
On Wed, Nov 10, 2010 at 7:01 PM, Andrew Dunstan wrote:
The current name causes constant confusion. It's a significant misnomer, and
leads people to distrust the code. There might be reasons not to change, but
you should at least recognize why the sug
On Wed, Nov 10, 2010 at 8:05 PM, Andrew Dunstan wrote:
> On 11/10/2010 07:51 PM, Robert Haas wrote:
>> On Wed, Nov 10, 2010 at 7:01 PM, Andrew Dunstan
>> wrote:
>>>
>>> The current name causes constant confusion. It's a significant misnomer,
>>> and
>>> leads people to distrust the code. There mi
On 11/10/2010 06:17 PM, Tom Lane wrote:
"David E. Wheeler" writes:
On Nov 10, 2010, at 2:15 PM, Andrew Dunstan wrote:
We already use some contrib stuff in the regression tests. (It really is time
we stopped calling it contrib.)
Call them "core extensions". Works well considering Dimitri's
13 matches
Mail list logo
