Re: [PATCH v1 1/1] Add GENERATED ALWAYS AS ROW IDENTITY columns

From: Hannu Krosing <hannuk(at)google(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v1 1/1] Add GENERATED ALWAYS AS ROW IDENTITY columns
Date: 2026-10-23 18:39:36
Message-ID: CAMT0RQR74uWvLdL5FA2je-VPkKkiZs6+-aOgDJ_yKsrDkbNc0Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 23, 2026 at 1:41 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> On 2026-Oct-23, Hannu Krosing wrote:
>
> > This is something I have been thinking of for some time and here is a
> > proof of concept implementation to verify the advantages I have hoped
> > it will have.
>
> I think you have to stop flooding this list with code that nobody wrote
> and nobody will read.

This was not meant to be final in any way; it was meant to introduce
an *idea* with a PoC implementation for people who want to verify its
merits.

Was marking it [PATCH] the main confusing thing, or was there also
something else?

...
>
> I want progress here, I really do, but this is not the way.

What do you think would be a good way to discuss larger ideas that go
beyond bugfixes ?

> (*) The latest pgbench post was stuck in the moderator queue because of
> the message size. I was looking at it earlier today, thinking ... 3 MB
> of code ... should I just reject it? In the end, it's not the
> moderator's job to take that kind of shot, so it's now published.

Thanks!
I expect this to be complete for some time regarding the planned functionality.

The thing is actually about 5 or six individual patches that need to
be applied one after another, first pure moving code from a single one
into into separate files, then more structural refactoring,

And only after that come the actual enhancements and new features.

I now plan to start discussions about adding a patch linking feature
to the commitfest app, so one does not need to post same patches in
multiple entries (I found 23 such cases over last few years)

> But
> you should know better than to post multiple 400kB patches of new
> features of unknown quality that have never before even been mentioned
> in this list, much less discussed about or agreed, in a "Refactor
> pgbench code" subject thread.

The first 10 patches are indeed refactoring.

And I did not want to open another entry that included all the
refactoring, so I explained it in the email and the CF entry

----
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Manu 2026-10-23 19:43:16 Re: Incremental backup can use a summary past a timeline switch
Previous Message Greg Burd 2026-10-23 18:21:04 Re: Tepid: selective index updates for heap relations