Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I merely said that the way the patch was presented, with significant
> > code refactoring mixed in, I couldn't review it (as effectively as
> > perhaps otherwise). FWIW, I believe that the general approach is
> > sound, but I ha
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> >
> >
> >> My post below was merely to agree with Tom that in principle, patches
> >> should be be reviewed before application and not after. I still think
> >> that's right - I have been concerned lately that the buildfarm has been
> >> broken
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I merely said that the way the patch was presented, with significant
> code refactoring mixed in, I couldn't review it (as effectively as
> perhaps otherwise). FWIW, I believe that the general approach is
> sound, but I haven't actually "reviewed"
Andrew Dunstan wrote:
> If you and Peter have reviewed it thoroughly then I see no reason the
> patch should not be applied.
I merely said that the way the patch was presented, with significant
code refactoring mixed in, I couldn't review it (as effectively as
perhaps otherwise). FWIW, I believ
Bruce Momjian wrote:
My post below was merely to agree with Tom that in principle, patches
should be be reviewed before application and not after. I still think
that's right - I have been concerned lately that the buildfarm has been
broken a bit too much.
Well, just because they are
Andrew Dunstan wrote:
>
> Bruce,
>
> I think you have misunderstood.
>
> If you and Peter have reviewed it thoroughly then I see no reason the
> patch should not be applied.
We have. I did extensive rework, and Peter exchanged emails with the
author asking questions. I did have questions abo
Bruce,
I think you have misunderstood.
If you and Peter have reviewed it thoroughly then I see no reason the
patch should not be applied.
My post below was merely to agree with Tom that in principle, patches
should be be reviewed before application and not after. I still think
that's right
Zdenek Kotala wrote:
> Bruce, Andrew, Tom.
>
> I little bit confuse now, what status of this patch is? I check your
> observation and I agree with them. But I don't where is "ball" now and
> what I can/must do now like author of this patch?
I am unsure too. I would not back out a patch for non
Bruce, Andrew, Tom.
I little bit confuse now, what status of this patch is? I check your
observation and I agree with them. But I don't where is "ball" now and
what I can/must do now like author of this patch?
Thanks for explanation
Zdenek
Bruce Momjian napsal(a):
OK, wi
OK, with two people now concerned, patch reverted.
---
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > I've always found it easier to review uncommitted patches than committed
> > ones anyway. When you're playing catch-up
Tom Lane wrote:
I've always found it easier to review uncommitted patches than committed
ones anyway. When you're playing catch-up by reviewing a committed
patch, you have to deal with three states of the code rather than two
(pre-patch, post-patch, your own mods). That gets rapidly worse if
Bruce Momjian <[EMAIL PROTECTED]> writes:
> There were three things wrong with the original patch:
> o spacing, e.g. "if( x =- 1 )"
> o an incorrect API for memory freeing by parse_value()
> o verify_config_option() didn't consider custom variables
> These have all been corre
Tom Lane wrote:
BTW, do I need to mention that the plperl patch is breaking the
buildfarm again?
No :-) See my comments from about an hour ago. It needs to be removed also.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' t
Michael Fuhr <[EMAIL PROTECTED]> writes:
> The latest HEAD is segfaulting on startup if I have the following
> lines in postgresql.conf:
> custom_variable_classes = 'plperl'
> plperl.use_strict = on
Bruce, please re-revert that GUC patch and don't put it back in until
someone like Peter or me has
Michael Fuhr wrote:
> The latest HEAD is segfaulting on startup if I have the following
> lines in postgresql.conf:
>
> custom_variable_classes = 'plperl'
> plperl.use_strict = on
>
> If I comment out the second line then the server starts successfully.
> Platform is Solaris 9/sparc.
>
> (gdb) b
The latest HEAD is segfaulting on startup if I have the following
lines in postgresql.conf:
custom_variable_classes = 'plperl'
plperl.use_strict = on
If I comment out the second line then the server starts successfully.
Platform is Solaris 9/sparc.
(gdb) bt
#0 0xff0340a0 in strcmp () from /usr/
16 matches
Mail list logo
