IMO it's wrong to change an aggregate's meaning from "aggregate across
GROUPs or entire SELECT" to "aggregate within column". Aggregation is
long established in SQL and it will just confuse experienced database
users.
PostgresQL maintains the meaning of max:
CREATE TABLE tab (
x int[]
);
INS
Agree with views, or alternatively, column permissions together with
computed columns:
CREATE TABLE foo (
id int PRIMARY KEY,
unmasked_name text,
name text GENERATED ALWAYS AS some_mask_function(text, 'xxx', 7)
)
(syntax from postgresql)
GRANT SELECT ON foo.name TO general_use;
G
k McFadin wrote:
The replies got trashed pretty badly in the responses.
When you say: "Agree it's better to reuse existing syntax than invent
new syntax."
Which syntax are you referring to?
Patrick
On Mon, Aug 22, 2022 at 1:36 AM Avi Kivity via dev
wrote:
Agree it's b
Agree it's better to reuse existing syntax than invent new syntax.
On 8/21/22 16:52, Konstantin Osipov wrote:
* Avi Kivity via dev [22/08/14 15:59]:
MySQL supports SELECT INTO FROM ... WHERE
...
PostgreSQL supports pretty much the same syntax.
Maybe instead of LET use the ANSI/
On 18/08/2022 18.46, Mick Semb Wever wrote:
Until IDEs auto cross-reference JIRA,
I'm going to lightly touch the lid of Pandora's Box here and walk
away slowly. It drives me *nuts* when I'm git blaming a file to
understand the context of why a change was made (to make sure I
.
LET (a, b, (c, d)) = SELECT a, b, someTuple FROM..
IF a > 1 AND d > 1…
I think this can be safely deferred. Most people would again separate it
into separate LETs.
I'd add (to the specification) that LETs cannot override a previously
defined variable, just to reduce ambiguity.
On 14/08/2022 01.29, Benedict Elliott Smith wrote:
I’ll do my best to express with my thinking, as well as how I would
explain the feature to a user.
My mental model for LET statements is that they are simply SELECT
statements where the columns that are selected become variables
accessibl
