| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | Junwang Zhao <zhjwpku(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Julien Tachoires <julien(at)tachoires(dot)me> |
| Subject: | Re: Allow table AMs to define their own reloptions |
| Date: | 2026-09-10 17:50:39 |
| Message-ID: | 3441d44c-389b-4d8c-bd2b-3539c136e376@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-09-07 Mo 8:41 AM, Aleksander Alekseev wrote:
> Hi Andrew,
>
>> Attached is v7. Changes since v6:
>>
>> [...]
> That's an important feature, thanks for driving it. We wanted
> something like this in the recent commit 0e944fe3 but ended up using a
> GUC.
>
> There is one important design difference however. Your patch allows
> given TAMs to have their own reloptions. In 0e944fe3 the task was
> different. An extension that doesn't implement a TableAM should be
> able to extend `CREATE TABLE foo WITH (...)` with its own options
> independent of the underlying TAM. The way these options are
> interpreted depends on the extension, not the underlying TAM.
>
> If we could separate reloptions extension from TAM implementation that
> would be much more flexible. Do you think it's possible?
I kind of feel like that's a separate project, and I'm not keen to hold
this one up for scope creep.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-09-10 18:09:56 | Re: REPACK (CONCURRENTLY) fails when replica identity index is dropped |
| Previous Message | Robert Haas | 2026-09-10 17:40:07 | Re: PGQ catalog representation and pg_dump support |