On Mon, Jul 18, 2016 at 11:13 AM, Tom Lane wrote:
>> I don't particularly like your suggestion of spooky action at a
>> distance between force_parallel_mode and regression_test_mode. That
>> just seems kooky.
>
> It's certainly a judgment call as to which way is cleaner, but
On Mon, Jul 18, 2016 at 1:34 AM, Michael Paquier
wrote:
> One downside of the plugin is that any users willing to do make
> installcheck would need to install it as well.
Not really. If the only purpose of the plugin is to verify that we're
not creating regression
Peter Eisentraut writes:
> On 7/15/16 6:13 PM, Tom Lane wrote:
>> We've talked before about how the regression tests should be circumspect
>> about what role names they create/drop, so as to avoid possibly blowing
>> up an installation's existing users during
On 7/15/16 6:13 PM, Tom Lane wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck".
I'm not particularly sure that that is a
Robert Haas writes:
> On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane wrote:
>> I'm coming to the conclusion that the only thing that will make this
>> materially better in the long run is automatic enforcement of a convention
>> about what role names may be
On Mon, Jul 18, 2016 at 10:37 AM, Robert Haas wrote:
> On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane wrote:
> We could also do this by loading a C module during the regression
> tests, which seems maybe less ugly than adding a GUC.
> I don't particularly
On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane wrote:
> I'm coming to the conclusion that the only thing that will make this
> materially better in the long run is automatic enforcement of a convention
> about what role names may be created in the regression tests. See my
>
I've gone ahead and pushed a patch that does all of the cosmetic renamings
needed to clean up the global-object-names situation. I've not done
anything yet about those special cases in the rolenames test, since it's
open for discussion exactly what to do there. I figured that this patch
was
Alvaro Herrera writes:
> Tom Lane wrote:
>> We've talked before about how the regression tests should be circumspect
>> about what role names they create/drop, so as to avoid possibly blowing
>> up an installation's existing users during "make installcheck". In
>>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> One could certainly argue that these are safe enough because nobody would
>> ever create real roles by those names anyway. I'm not very comfortable
>> with that though; if we believe that, why did we go to the
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck". In
> particular I believe there was
On 16 Jul 2016 12:59 pm, "Michael Paquier"
wrote:
>
> Thanks for doing this.
+1
Though I might highlight this as the kind of issue that a bug tracker would
help avoid falling through the cracks and make visible to newcomers.
> I am -1 for dropping the tests. We
On Sat, Jul 16, 2016 at 7:13 AM, Tom Lane wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck". In
>
Tom Lane wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck". In
> particular I believe there was consensus that such names
14 matches
Mail list logo