Re: [PATCH] ALTER TABLE ... SET STORAGE default

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: Nikita Malakhov <hukutoc(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] ALTER TABLE ... SET STORAGE default
Date: 2022-11-05 17:45:59
Message-ID: 2623256.1667670359@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
> Hi Nikita,
>> This seems a little bit confusing and thus very unfriendly for the user, because the actual meaning
>> of the same 'DEFAULT' option will be different for each data type, and to check storage mode user
>> has to query full table (or column) description.
>> I'd rather add a paragraph in documentation describing each data type default storage mode.

> I agree that "SET STORAGE default" syntax leaves much to be desired.

FWIW, I don't buy that argument at all. If you believe that then
you must also think that

INSERT INTO mytab VALUES (..., DEFAULT, ...);

is a poorly-designed feature because you have to go consult the table
definition to find out what will be inserted. (Well, maybe you do
think that, but the SQL committee won't agree with you ;-)) So I don't
see any problem with DEFAULT representing a data-type-specific default
in this situation.

> Personally I would prefer "RESET STORAGE" and "RESET COMPRESSION".

Perhaps, but what's done is done, and I agree that STORAGE had better
follow the existing precedent.

I've not read the patch in any detail, but I don't see a problem
with the design.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-11-05 18:22:56 Re: pg_reload_conf() synchronously
Previous Message Corey Huinker 2022-11-05 17:39:09 Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands