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 1sWIs2-00ENnK-R7 for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jul 2024 17:00:14 +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 1sWIrz-00Ewds-LI for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jul 2024 17:00:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sWIrz-00Ewdk-Bb for pgsql-hackers@lists.postgresql.org; Tue, 23 Jul 2024 17:00:11 +0000 Received: from mail-oo1-xc2a.google.com ([2607:f8b0:4864:20::c2a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWIrx-0015Xn-8s for pgsql-hackers@postgresql.org; Tue, 23 Jul 2024 17:00:11 +0000 Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-5ce74defe43so3073879eaf.2 for ; Tue, 23 Jul 2024 10:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721754007; x=1722358807; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7DBCUC9p/MFUIhEOSGhfCpPXI6PApbe6L1doM9LausU=; b=He2CdSdAt6EaDkiRJBS6MKCrGHru9cL21VYWGUa2GEWzEVH77HNcbSayPhbRC8Pd0g rdfeQUy9xhNo+xzeKVXxOKhKkZy1QdIa3TMDjcVW+wVv+a6WP7gdRtT/T6JB3qpAq+xO 6Cm/BbzvpoawwUrB7pEtWclKK0APrG7F09uguulH2wLZx8Ei7nY8y3ginGXKFGbSPE4G ZuXAiSG3rBaHwhFLRyUkSQDLVV2Knk/dEv+fza07faaEMxftpsq6XY8wMZ/uRODgsBov w4D+HNlCeDEu48DM1p8UyckHiE2FjiSQvfrFpcZFIUrMG+XivWBWwnIfNs7dwmdE3kc5 HEFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721754007; x=1722358807; 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=7DBCUC9p/MFUIhEOSGhfCpPXI6PApbe6L1doM9LausU=; b=SlrWht6I+rwgEfdQSMb1G+RFzSEamrUp2ipp2gY9SxZXFkJb3Nb42myylRXVulw7Kz wkJAsjoP0gMKHaJDSWHGlmgDYMQHCD8qbeWcV7u3kHNES6xxduVtUq1jrhZeKdiUlOf+ O749EG0Gqi1ajQJPXEHKzagJE5ZOsYHnYXsGXDVa59lEPMfTkONhJQLvM1KTVwy64ong FZNcqqT4Y2Epwb5rqEXU8qeunqdVGXCkhvsBs30mn3fn2hmGWcqvRFu2vtKgANl+GKec UxH+nCVIyEV05S4JyQVXeEVFraAWBOhXHRWgod4NzZsQD3Rjdnwq+DlmZDFNB8qBmm33 3RtA== X-Forwarded-Encrypted: i=1; AJvYcCUUfUhNcKuweDY5JELnWJzQUaIa+vDHFNV3N0zx3rfamxW2h6LxpjDA1ZJYN3m73HYnGy630g6QyfrWZK6Uip+2opKfSXa2UaR1gerk X-Gm-Message-State: AOJu0Yzd2zxJFg8q1nqyVhP0w071IyckWySzqvgmWztA5SrUkH+FMVcg LxKGRDe6XwvkZvFcmn3SG3L3j4qOwu132E9Pv1lWPad25HThLnp1CvgyKLtFhWtX02BwwOeQYN2 o8ITILR/rhqgnvH0oV+cAwf9ULUI= X-Google-Smtp-Source: AGHT+IFrZr1FBPymXtgSdp6ZEBBktk688srgKiI7X5pK5SQ84kdnI4jgTV2hxTNhsYsjOVhG8jTIZVC3+D9cPPsH4Es= X-Received: by 2002:a05:6820:290c:b0:5c4:4aaa:d245 with SMTP id 006d021491bc7-5d58b7ce4b1mr4369537eaf.5.1721754006503; Tue, 23 Jul 2024 10:00:06 -0700 (PDT) MIME-Version: 1.0 References: <931747.1721687375@sss.pgh.pa.us> <39aca36b0e570a9f53dc1740f0de81ddffae0f1d.camel@cybertec.at> In-Reply-To: From: "David G. Johnston" Date: Tue, 23 Jul 2024 09:59:29 -0700 Message-ID: Subject: Re: [PATCH] GROUP BY ALL To: David Christensen Cc: Laurenz Albe , Tom Lane , pgsql-hackers Content-Type: multipart/alternative; boundary="000000000000f2cba8061ded1713" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f2cba8061ded1713 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2024 at 9:48=E2=80=AFAM David Christensen wrote: > > Sure, not everything that makes things easier is strictly necessary; > we could require `CAST(field AS text)` instead of `::text`, Probably should have...being standard and all. Though syntactic sugar is quite different from new behavior - transforming :: to CAST is straight-forward. make > subqueries required for transforming oids into specific system tables > instead of `::regfoo` casts, Since OID is non-standard this falls within our purview. any number of other choices, remove > `SELECT *` as a parse option, Again, standard dictated. but making it easier to do common things > interactively as a DBA has value as well. > > Agreed, but this isn't a clear-cut win, and doesn't have standard conformance to tip the scale over fully. Also, there are so many better tools for data exploration. Removing this quirk only marginally closes that gap. David J. --000000000000f2cba8061ded1713 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2024 at 9:48=E2=80=AFAM David Christensen = <david@pgguru.net> wrote:

Sure, not everything that makes things easier is strictly necessary;
we could require `CAST(field AS text)` instead of `::text`,

Probably=C2=A0should=C2=A0have...being standard and all.=C2= =A0 Though syntactic sugar is quite different=C2=A0from new behavior - tran= sforming :: to CAST is straight-forward.

make
subqueries required for transforming oids into specific system tables
instead of `::regfoo` casts,

Since OID i= s non-standard this falls within our purview.

=C2=A0 any number of other c= hoices, remove
`SELECT *` as a parse option,

Again, standard= dictated.

but making it easier to do common things
interactively as a DBA has value as well.


Agreed, but this isn't a clear-cut win, and doesn't have stand= ard conformance to tip the scale over fully.

Also, t= here are so many better tools for data exploration.=C2=A0 Removing=C2=A0thi= s quirk only marginally closes that gap.

David J.

--000000000000f2cba8061ded1713--