Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sWXnx-00Fntj-DF for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jul 2024 08:57:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sWXnv-002f7R-Cn for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jul 2024 08:56:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sWXnv-002f7J-2d for pgsql-hackers@lists.postgresql.org; Wed, 24 Jul 2024 08:56:59 +0000 Received: from mail-yb1-f172.google.com ([209.85.219.172]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWXns-001AqH-Qj for pgsql-hackers@postgresql.org; Wed, 24 Jul 2024 08:56:58 +0000 Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-dfe43dca3bfso6347497276.0 for ; Wed, 24 Jul 2024 01:56:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721811414; x=1722416214; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E6zsBvB3elIvLB/+G+xe6bC7bDj4APTwHJG8eY6OZnc=; b=KsJQiVmXkqj6kiCBfXUVWY24pkg20a1+oXpVhfb7dPCb+MtCQREzl+AF4bRzfpYplv pqeF7SdNjVfVmNZ2F7tGG85ZCPNuIgLRHNN1I2n/f7gVY7GbC9hoFpOBYeepaau+/dwQ l3M0X7foSJ1lowBsy3e6LeeeqEuCefYLn7pWBf7JTBgZviakfn6czHFCtWWi7BeKk8v7 WZcHcYFl65sEkPyfn7tZ7q4ghjKHcRxJxnBs/20L1VmDTEMZXkLlfXHcQb+0C8DhPz+j 20FOC7eJUsNffChbRJ9qcw2i0z58p7dujhfMclzsljBX8gW5LKIP0Xopo4l8jaMA5jkF FVPw== X-Gm-Message-State: AOJu0YxsmF4qHEs1cG9OTur6axCLSIi4N1yrya8LZ/I6xo9pHab8otGO ScIrO03eXHjHMdIljdTlk7v6xSB1WfRQAD3oduPnpciVBGCiXtPnHEqTyyAOJX8GB1bBrRuBxLy ZVcWfkM/LcigBP4aboGth05bK3TDA4AJDEARdAQXEEX4meXVBVxxM1w== X-Google-Smtp-Source: AGHT+IElT/w7QKmaAEiEd3QTHueXNfj8aP1r0DVw+BVSFbH7pk4UQnqATT0I70+t/uJ9aocKPWNQoxW8nxN+QJZUPns= X-Received: by 2002:a05:6902:2847:b0:dff:137:b5cb with SMTP id 3f1490d57ef6-e0b0e404da7mr1505263276.23.1721811414482; Wed, 24 Jul 2024 01:56:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jelte Fennema-Nio Date: Wed, 24 Jul 2024 10:56:43 +0200 Message-ID: Subject: Re: [PATCH] GROUP BY ALL To: David Christensen Cc: pgsql-hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 22 Jul 2024 at 22:55, David Christensen wrote: > I see that there'd been some chatter but not a lot of discussion about > a GROUP BY ALL feature/functionality. There certainly is utility in > such a construct IMHO. +1 from me. When exploring data, this is extremely useful because you don't have to update the GROUP BY clause every time Regarding the arguments against this: 1. I don't think this is any more unreadable than being able to GROUP BY 1, 2, 3. Or being able to use column aliases from the SELECT in the GROUP BY clause. Again this is already allowed. Personally I actually think it's more readable than specifying e.g. 5 columns in the group by, because then I have to cross-reference with columns in the SELECT clause to find out if they are the same. With ALL I instantly know it's grouped by all 2. This is indeed not part of the standard. But we have many things that are not part of the standard. I think as long as we use the same syntax as snowflake, databricks and duckdb I personally don't see a big problem. Then we could try and make this be part of the standard in the next version of the standard.