Month: September 2025

I want to wrap this saga with something honest rather than conclusive.

I posted ideas to the Oracle Community in 2016. Two of them — GROUP BY OTHERS and Oracle Tagging for Objects — bear a striking resemblance to features shipped in Oracle 23ai eight years later: GROUP BY ALL and the ANNOTATIONS clause. The syntax is nearly identical. The motivation is the same. The use cases I described are the exact use cases Oracle used in their documentation.

I sent an email to Oracle in August 2025 asking for credit in the documentation. A small request. Being acknowledged as the person who suggested a feature that’s now documented in Oracle’s official manuals would be meaningful.

I’m not writing this as an accusation. I’m writing it because I think the community deserves to know how the relationship between feedback and implementation works – or doesn’t. Thousands of developers, DBAs, and architects contribute ideas to vendor forums every year. Most go nowhere. A few get implemented. Rarely are contributors thanked.

If your idea becomes a product feature, you may never know. If it does, the credit usually stays internal.

I think that should change. Not through legal mechanisms – these are ideas, not patents – but through culture. It costs nothing to say “this idea came from community feedback, including a 2016 post by Matheus Boesing.” Nothing except the will to do it.

The Oracle community has given Oracle an enormous amount over the years: bug reports, feature requests, presentations, blog posts, conference sessions. A little acknowledgment goes a long way.

THE SAGA: “The Features I Suggested, Oracle Implemented — A Personal History”

This is a five-part series about two Oracle SQL features introduced in Oracle Database 23ai that are strikingly similar — in concept, motivation, and syntax — to suggestions I posted in the Oracle Community forums in July 2016, nearly a decade before they were implemented.

Not every idea maps cleanly to a shipped feature. This one is more speculative — and I want to be honest about that.

In 2016, I also posted an idea I called “CTAS with built-in Autodrop”. The concept was a CREATE TABLE AS SELECT that included a lifecycle clause — a way to define, at creation time, that the table should be automatically dropped (or archived) after a certain time or condition.

CREATE TABLE temp_report AS
SELECT * FROM orders WHERE order_date < SYSDATE - 30
AUTODROP AFTER 7 DAYS;

The motivation: temporary working tables created for reports, ETL staging, or analysis are often forgotten. They accumulate. Giving the database a built-in way to manage their lifecycle would reduce clutter and DBA overhead.

In Oracle 12c, Oracle shipped Automatic Data Optimization (ADO) — a feature under the Information Lifecycle Management umbrella that automatically manages data based on policies (heat maps, tiering, compression, archiving). My CTAS Autodrop idea predated ADO’s expanded feature set, though some of ADO’s core concepts were already in the works.

Did my idea seed any part of ADO? Honestly, I don’t know. I said as much in my email to Gerald Venzl:

“It was suggested before the Automatic Data Optimization (ADO) was released, so it could have been something like a seed to all of it. But then I may not be able to claim, exactly.”

That’s fair. ADO is far broader than my suggestion. The connection is more conceptual than syntactic.

What I will say: the Oracle Ideas forum in 2016 was read by product managers. Ideas were evaluated. And this one described a gap that Oracle recognized and eventually addressed — in their own way, on their own timeline.

Link to my original 2016 post: https://forums.oracle.com/ords/apexds/post/ctas-with-built-in-autodrop-5261

THE SAGA: “The Features I Suggested, Oracle Implemented — A Personal History”

This is a five-part series about two Oracle SQL features introduced in Oracle Database 23ai that are strikingly similar — in concept, motivation, and syntax — to suggestions I posted in the Oracle Community forums in July 2016, nearly a decade before they were implemented.

Also on July 2, 2016 — the same day I posted the GROUP BY OTHERS idea — I posted another suggestion to the Oracle Community: “Oracle Tagging for Objects”.

Here’s what I described:

“It’s more than comments, it consists in add indexable keywords that enable easily locate tables or other objects in database, like Mac OS and other systems allow to tag files.”

I proposed a TAGS keyword for DDL, with this example syntax:

CREATE TABLE example (a NUMBER, b NUMBER) TAGS ('Transactional'[,...]);
CREATE SEQUENCE seq_exemp ON example TAGS ('Transactional');
CREATE INDEX idx_oltp ON example TAGS ('Transactional');

And a way to query tags:

SELECT OBJECT_NAME, OBJECT_TYPE, TAG
FROM DBA_TAGS
WHERE TAG = 'Transactional';

I also proposed that tags could have key-value form:

TAGS ('Transactional', 'John');

Now look at Oracle 23ai’s Annotations clause, introduced in 2024:

CREATE TABLE example (a NUMBER, b NUMBER)
ANNOTATIONS (Transactional, Owner 'John');

SELECT object_name, annotation_name, annotation_value
FROM user_annotations_usage;

The concept: identical. The syntax: nearly identical. The query dictionary view: the same idea. The name changed from TAGS to ANNOTATIONS, the keyword changed from TAGS(...) to ANNOTATIONS(...), but everything else maps directly.

My 2016 idea was posted eight years before the implementation. The Oracle Ideas forum was active. People voted on ideas, product managers read them.

A mention in the documentation would be nice, nothing more. I think that’s fair, even for an idea implemented a decade later. Maybe especially for one implemented a decade later. Don’t you think?

Link to my original 2016 post: https://forums.oracle.com/ords/apexds/post/oracle-tagging-for-objects-9158

THE SAGA: “The Features I Suggested, Oracle Implemented — A Personal History”

This is a five-part series about two Oracle SQL features introduced in Oracle Database 23ai that are strikingly similar — in concept, motivation, and syntax — to suggestions I posted in the Oracle Community forums in July 2016, nearly a decade before they were implemented.

On July 2, 2016, I posted an idea to the Oracle Community Database Ideas forum. The title was “SQL Syntax: GROUP BY OTHERS”.

Here’s the core of what I proposed:

“So, to make it simpler, it could exists a ‘GROUP BY OTHERS’ that group all selected columns that are not under aggregate functions.”

I demonstrated it with this example:

SELECT COUNT(*), SUM(salary), AVG(salary), AVG(age),
       company, state, country
FROM company_employees
GROUP BY OTHERS;

My point was clear: developers shouldn’t have to repeat every non-aggregated column in the GROUP BY clause. The database should be smart enough to infer it. I even acknowledged that the keyword didn’t have to be OTHERS — I mentioned GROUP BY all, GROUP BY everythingelse, among others. The idea was the important part.

In Oracle 23ai (released May 2024), the feature landed as GROUP BY ALL. The syntax:

SELECT COUNT(*), SUM(salary), AVG(salary), company, state, country
FROM company_employees
GROUP BY ALL;

The motivation is identical. The behavior is identical. The keyword ALL was one of the alternatives I explicitly mentioned in a comment on my own post.

I’m not saying this proves Oracle implemented my idea. What I’m saying is that the timing of my suggestion — 2016 — and the implementation — 2024 — represents roughly an eight-year gap, during which the Oracle Ideas forum was maintained by Oracle’s product management team. These ideas were read. They were evaluated. And this particular one was implemented.

A credit in the documentation would have been appropriate. In my opinion, it still would be.

Link to my original 2016 post: https://forums.oracle.com/ords/apexds/post/sql-syntax-group-by-others-0435

THE SAGA: “The Features I Suggested, Oracle Implemented — A Personal History”

This is a five-part series about two Oracle SQL features introduced in Oracle Database 23ai that are strikingly similar — in concept, motivation, and syntax — to suggestions I posted in the Oracle Community forums in July 2016, nearly a decade before they were implemented.

Back in 2016, I was deep in the Oracle ACE program — eventually ACE Director for four years — and spending a lot of time in the Oracle Community forums. At the time, Oracle had a space called “Database Ideas” where community members could suggest improvements to the database.

I posted several ideas. Two of them, I believe, were implemented in Oracle Database 23ai, roughly eight years later. The features are GROUP BY ALL and SQL Annotations.

I want to be careful about how I frame this. I’m not claiming Oracle copied my ideas. Large engineering organizations like Oracle receive countless community suggestions, conduct internal research, and implement features based on their own roadmap priorities. It’s entirely possible — likely, even — that these features were conceived independently by Oracle’s SQL language team.

What I am saying is this: the similarities are striking. Not just in concept, but in the specific syntax and motivation I described. And I was never contacted, credited in the documentation, or mentioned in any release notes.

Over the next four weeks, I’ll walk through each feature:

• Sep 8: GROUP BY ALL — my 2016 suggestion vs. the 23ai implementation
• Sep 15: Annotations — my “Oracle Tagging for Objects” idea vs. the Annotations clause
• Sep 22: CTAS with Autodrop — a related idea that may have seeded ADO
• Sep 29: Reflections on being an uncredited contributor

I’m writing this series not to be bitter — I’m genuinely proud that ideas I had are now real Oracle features — but because I think it’s worth talking about the relationship between community feedback and product development. Transparency matters.