On Thu, Mar 20, 2025 at 09:59:45AM -0700, David G. Johnston wrote:
> I get the need for this kind of logic, since we used a boolean for the
> table option, but as a self-proclaimed hack it seems worth more comments
> than provided here. Especially pertaining to whether this is indeed
> generic or vacuum_truncate specific. It's unclear since both isset and
> vacuum_truncate_set have been introduced.
I'm happy to expand the comments, but...
> If it is now a general property
> applying to any setting then vacuum_truncate_set shouldn't be needed - we
> should just get the isset value of the existing vacuum_truncate reloption
> by name.
the reason I added this field is because I couldn't find any existing way
to get this information where it's needed. So, I followed the existing
pattern of adding an offset to something we can access. This can be used
for any reloption, but currently vacuum_truncate is the only one that does.
I'll come back to the comment if it's needed. I was concerned about dump/restore and apparently pg_dump has been perfectly capable of determining whether the current catalog state for a reloption, even a boolean, is unset, true, or false. Namely, the following outcomes:
create table vtt (x int not null, y int not null);
CREATE TABLE public.vtt (
x integer NOT NULL,
y integer NOT NULL
);
alter table vtt set (vacuum_truncate = true);
CREATE TABLE public.vtt (
x integer NOT NULL,
y integer NOT NULL
)
WITH (vacuum_truncate='true');
alter table vtt reset (vacuum_truncate);
CREATE TABLE public.vtt (
x integer NOT NULL,
y integer NOT NULL
);
So my concern about dump/restore seems to be alleviated but then, why can we not just do whatever pg_dump is doing to decide whether the current value for vacuum_truncate is its default (and thus would not be dumped) or not (and would be dumped)?
David J.
