On 2020-07-02 17:25, James Coleman wrote:
I think the change makes a lot of sense. The only reason I had it as
enable_incrementalsort in the first place was trying to broadly
following the existing GUC names, but as has already been pointed out,
there's a lot of variation there, and my version of
I think the change makes a lot of sense. The only reason I had it as
enable_incrementalsort in the first place was trying to broadly
following the existing GUC names, but as has already been pointed out,
there's a lot of variation there, and my version of the patch already
changed it to be more rea
On Mon, Jun 22, 2020 at 11:22 AM Bruce Momjian wrote:
> I think the big problem is that, without the extra underscore, it reads
> as increment-alsort. ;-)
I know you're joking, but I think there's a serious issue here. We
often both omit word separators and also abbreviate, and I doubt that
the
Bruce Momjian writes:
> On Mon, Jun 22, 2020 at 10:41:17AM -0400, Tom Lane wrote:
>> Maybe I'm just used to the names, but I find that things like
>> "enable_seqscan" and "enable_nestloop" are pretty readable.
>> Once they get longer, though, not so much. So I agree with
>> renaming enable_increm
On Mon, Jun 22, 2020 at 10:41:17AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra
> > wrote:
> >> The reason why I kept the single-word variant is consistency with other
> >> GUCs that affect planning, like enable_indexscan, enable_hashjoin and
> >>
On Mon, Jun 22, 2020 at 10:31 AM Tomas Vondra
wrote:
> OK, challenge accepted. $100 to the first person who commits a patch
> with a variable NaMeS___LiKeTh_is.
:-)
Well, that was hyperbole, but people have proposed some pretty wacky
schemes, and a few of those have ended up in the tree. For exa
Robert Haas writes:
> On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra
> wrote:
>> The reason why I kept the single-word variant is consistency with other
>> GUCs that affect planning, like enable_indexscan, enable_hashjoin and
>> many others.
> Right, so that makes sense, but from a larger point of
On Mon, Jun 22, 2020 at 10:16:54AM -0400, Robert Haas wrote:
On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra
wrote:
The reason why I kept the single-word variant is consistency with other
GUCs that affect planning, like enable_indexscan, enable_hashjoin and
many others.
Right, so that makes sens
On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra
wrote:
> The reason why I kept the single-word variant is consistency with other
> GUCs that affect planning, like enable_indexscan, enable_hashjoin and
> many others.
Right, so that makes sense, but from a larger point of view, how much
sense does it
On Mon, Jun 22, 2020 at 4:48 AM David Rowley wrote:
>
> On Sun, 21 Jun 2020 at 23:22, Tomas Vondra
> wrote:
> >
> > On Sun, Jun 21, 2020 at 09:05:32AM +0200, Julien Rouhaud wrote:
> > >On Sun, Jun 21, 2020 at 8:26 AM Peter Eisentraut
> > > w
On Sun, 21 Jun 2020 at 23:22, Tomas Vondra wrote:
>
> On Sun, Jun 21, 2020 at 09:05:32AM +0200, Julien Rouhaud wrote:
> >On Sun, Jun 21, 2020 at 8:26 AM Peter Eisentraut
> > wrote:
> >>
> >> I suggest to rename enable_incrementalsort to enable_increment
On Sun, Jun 21, 2020 at 09:05:32AM +0200, Julien Rouhaud wrote:
On Sun, Jun 21, 2020 at 8:26 AM Peter Eisentraut
wrote:
I suggest to rename enable_incrementalsort to enable_incremental_sort.
This is obviously more readable and also how we have named recently
added multiword planner parameters
On Sun, Jun 21, 2020 at 8:26 AM Peter Eisentraut
wrote:
>
> I suggest to rename enable_incrementalsort to enable_incremental_sort.
> This is obviously more readable and also how we have named recently
> added multiword planner parameters.
>
> See attached patch.
+1, this is
I suggest to rename enable_incrementalsort to enable_incremental_sort.
This is obviously more readable and also how we have named recently
added multiword planner parameters.
See attached patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
14 matches
Mail list logo
